| 47ac18da | 15-Jul-2025 |
Ed Tanous <etanous@nvidia.com> |
Allow appending std::vector<bool>
std::vector<bool> when done with a for loop returns the type of
std::_bit_reference, which doesn't have a direct conversion to the
underlying boolean type.
Rather
Allow appending std::vector<bool>
std::vector<bool> when done with a for loop returns the type of
std::_bit_reference, which doesn't have a direct conversion to the
underlying boolean type.
Rather than relying on the type returned by begin(), rely on
T::value_type to specifically get the type in the container.
There isn't a particular use for this, but
https://gerrit.openbmc.org/c/openbmc/entity-manager/+/81474
Is trying to consolidate code, and having all types use the same
pack/unpack code is advantageous to avoid special cases. I don't
know of a place we're actually packing/unpacking arrays of bool.
Tested: Booted gb200nvl-bmc. Services launched, no new crashes seen.
Change-Id: I07fc150a190ae44f7bdc90531ad2a4ce7f47e0a1
Signed-off-by: Ed Tanous <etanous@nvidia.com>
show more ...
|
| 242677a2 | 27-Mar-2024 |
Ed Tanous <ed@tanous.net> |
Use sd-bus array methods for read and append
Currently sdbusplus uses sd_bus_message_read_basic and
message_append_basic for decoding and encoding of arrays. For large
arrays, this imposes a signif
Use sd-bus array methods for read and append
Currently sdbusplus uses sd_bus_message_read_basic and
message_append_basic for decoding and encoding of arrays. For large
arrays, this imposes a significant overhead in calling the library each
time. This leads to some extreme performance degradation in some cases,
for example, passing a 4K bytes data array over sdbusplus interface now
takes 4096 + 2 calls of sd_bus_message_read_basic and
message_append_basic, this will consume about 10ms CPU time on a Aspeed
2600 platform for each package on both send and receive side.
While in this case, a DBus interface design should likely opt for using
an FD rather than an array of bytes, this isn't a reason to not optimize
this case.
sd-bus, in version 240 added methods to deal with this performance
degradation, namely sd_bus_message_read_array and
sd_bus_message_append_array, which each only require a single call to
load values into the array using pointers and lengths.
This patchset is based on the one submitted here:
https://gerrit.openbmc.org/c/openbmc/sdbusplus/+/68614
But opts for a different approach to a number of technical details on
how it accomplishes the result, including changing the underlying sd-bus
calls used to utilize ones that don't require sdbus internal malloc,
avoiding unit tests ASAN issues in the process.
This commit adds support for utilizing the above methods when doing
calls to the library if the following requirements are met:
1. The container is contiguous (using the std::contiguous_iterator
concept)
2. The container represents a list of values of type int/uint 8,16,32,
or 64 bits wide. Note, per the sd-bus documentation, arrays of bool are
explicitly not supported (presumably because the internal representation
of a bool array for both libc++ and sd-bus is implementation defined).
To accomplish this, the arrays handling for contiguous arrays is moved
to use concepts, simplifying the code significantly, and allowing the
use of std::contiguous_iterator.
Change-Id: I3bd9f97ed160835e8c30c302b80553a1d450bbf9
Signed-off-by: Ed Tanous <ed@tanous.net>
Signed-off-by: Yongbing Chen <yongbingchen@google.com>
show more ...
|
| 88c6a823 | 10-Sep-2024 |
Lei YU <yulei.sh@bytedance.com> |
message: Fix unpack void type
The template unpack<void> is deduced as one argument instead of 0, and
results in below compile error:
```
error: variable or field ‘r’ declared void
error: return-stat
message: Fix unpack void type
The template unpack<void> is deduced as one argument instead of 0, and
results in below compile error:
```
error: variable or field ‘r’ declared void
error: return-statement with a value, in function returning ‘void’ [-fpermissive]
```
Fix this by checking void if `sizeof...(Args) == 1` and return void.
Also add a unit test case to make sure the code compiles.
Change-Id: I74cca180783645496863393be37215f1d6f4ca02
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
show more ...
|
| 8db46a0f | 05-May-2021 |
William A. Kennington III <wak@google.com> |
native_types: string_path_wrapper: Don't escape all strings
Not all strings require escaping when appending them to a path. This
allows us to now append `openbmc_project` to `/xyz` and have
expected
native_types: string_path_wrapper: Don't escape all strings
Not all strings require escaping when appending them to a path. This
allows us to now append `openbmc_project` to `/xyz` and have
expected behavior.
Change-Id: I49a2ee100455cff4067dcf3df61f3e145231eeba
Signed-off-by: William A. Kennington III <wak@google.com>
show more ...
|
| 285f78b1 | 01-May-2021 |
William A. Kennington III <wak@google.com> |
native_types: Reduce append allocation
This builds the string from left to right, instead of dealing with
string inserts, optimizing for allocations. Uses our own hex encoder
instead of relying on s
native_types: Reduce append allocation
This builds the string from left to right, instead of dealing with
string inserts, optimizing for allocations. Uses our own hex encoder
instead of relying on systemd libraries. This maintains explicit
compatability with the systemd encoding scheme.
Change-Id: Ia6c2f4fb19984f549c6bac2d67d0b5d610022038
Signed-off-by: William A. Kennington III <wak@google.com>
show more ...
|
| d06072e7 | 21-Apr-2021 |
Ed Tanous <edtanous@google.com> |
Fix #60 by adding encoding/decoding rules
This commit attempts to make encoding more compatible with things within
openbmc that don't encode paths per the systemd method. It does this by
forcing th
Fix #60 by adding encoding/decoding rules
This commit attempts to make encoding more compatible with things within
openbmc that don't encode paths per the systemd method. It does this by
forcing the first character of every path segment to be encoded, so /abc
would be encoded as /_61bc. This is then used as a mechanism to
determine if the path needs to be decoded per systemds rules.
The decode mechanisms are also modified to check whether the first
element is encoded before decoding the portion.
Looking for input on whether this is an OK path. The hope would be that
we slowly transition the system over to using the encoding mechanisms
that can handle all ascii characters, and can round trip through
encode/decode without loss. The hope is that this patch can be reversed
at some point in the future.
As an aside, I tried reverting some of the patches, but they're somewhat
ungainly to revert at this point, and would require reverting some
bmcweb patches, which, if this patch is determined to be bad, I'm happy
to do, but I'm hoping this will get us something in the interim
Tested:
unit tests added and updated to cover some of the cases. Unit tests
pass.
Change-Id: Ie9c8cd0627b8b086e8b0bb2287f28dd86eb98ee9
Signed-off-by: Ed Tanous <edtanous@google.com>
show more ...
|
| 74a27118 | 07-Apr-2021 |
Ed Tanous <edtanous@google.com> |
Implement operator /= for object_path
This probably should've been implemented as part of
fa0fa3b0fa5a9d59c37b6edbc53cc21b7c2a16b0 Implement path encoding and
decoding but alas, it was not. This co
Implement operator /= for object_path
This probably should've been implemented as part of
fa0fa3b0fa5a9d59c37b6edbc53cc21b7c2a16b0 Implement path encoding and
decoding but alas, it was not. This commit adds the relatively simple
operator/= overloads to object_path. This allows calling code to do
operations like:
object_path myPath("/foo");
myPath /= "bar";
Which would result in the object path /foo/bar.
In the implementation, this actually just calls into operator/, and does
a relatively naive replace of the content in the new object. Given how
the sd_bus_path_encode API is organized, there doesn't appear to be a
way to call into it and "append" to an existing thing, so constructing a
new string and assigning it to the current object was the best I could
come up with in terms of efficiency.
This includes overloads for both const char* and const std::string&,
both of which have essentially the same behavior.
Tested:
New unit tests included in commit, and pass.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Idfb7f7f2dc94ea3773841c9ae62cd671327db2cd
show more ...
|