Skip to content

Add BinarySerializer function that uses a thread-local shared buffer, and fix errors #921

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

erer1243
Copy link
Contributor

@erer1243 erer1243 commented Sep 24, 2024

Fixed dubious undefined behavior stemming from unaligned writes to the serialization buffer. Add serializeSharedBuffer which uses a shared 16MB buffer instead of requiring the caller to have one available. This would make c-api code which uses these functions significantly more efficient. If we like these changes, we can also change ZmqClient to use the shared buffer functions. Every ZmqClient currently allocates its own 16MB serialization buffer, so doing this would save a nonnegligible amount of memory.

Also fixed a couple misc errors - uninitialized array in tests/stringutility_ut.cpp made tests fail to compile; ZMQ_NOBLOCK was deprecated 6 years ago and is now called ZMQ_DONTWAIT. I just noticed these while making changes to & testing BinarySerializer.

Related: #915

@saiarcot895
Copy link
Contributor

saiarcot895 commented Sep 25, 2024

Can you elaborate on the undefined behavior that you saw from the unaligned writes?

@erer1243
Copy link
Contributor Author

erer1243 commented Sep 25, 2024

Can you elaborate on the undefined behavior that you saw from the unaligned writes?

Lines like these are UB, as they are writing a size_t to char*. These break strict aliasing/provenance and alignment rules. The WARNINGS_NO_CAST_ALIGN macro is telling gcc to not print the warning, but the problem still exists. The solution to both of these problems is memcpy, so I replaced those pointer casts with read/write_unaligned.

WARNINGS_NO_CAST_ALIGN;
auto pkvp_count = (const size_t*)buffer;
WARNINGS_RESET;

Unaligned reads/writes are acceptable on x86 & arm but isn't unheard of to break on embedded architectures. I'm not sure what hardware sonic supports - if we guarantee x86/arm then it's probably not an issue. Also if the optimizer decided to use a simd register (I have no idea if this would ever happen), then it would fault on x86 too. I thought it would be nicer to just sidestep the questions.

@saiarcot895
Copy link
Contributor

SONiC currently only supported amd64, armhf, and arm64, all of which support unaligned memory access (for armhf, ARMv7 and newer support it, which is what I think compile for). Nevertheless, it would be nice to allow SIMD operations by making sure the memory is aligned.

saiarcot895
saiarcot895 previously approved these changes Sep 25, 2024
@erer1243 erer1243 force-pushed the improve-serializer branch from 29faf00 to 39b2e81 Compare October 7, 2024 16:19
r12f pushed a commit that referenced this pull request Oct 30, 2024
Implement a C interface to some of libswsscommon in support of sonic-dash-ha.

Related:
sonic-net/sonic-dash-ha#6
#921

Incoming follow up PR:
erer1243#1

---------

Co-authored-by: erer1243 <[email protected]>
@erer1243 erer1243 closed this Nov 6, 2024
@erer1243 erer1243 deleted the improve-serializer branch November 6, 2024 04:48
{
{
// ZMQ socket is not thread safe: http://api.zeromq.org/2-1:zmq
std::lock_guard<std::mutex> lock(m_socketMutex);

// Use none block mode to use all bandwidth: http://api.zeromq.org/2-1%3Azmq-send
rc = zmq_send(m_socket, sendbuffer.data(), serializedlen, ZMQ_NOBLOCK);
// Use nonblocking mode to use all bandwidth: http://api.zeromq.org/2-1%3Azmq-send
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nonblocking

This fix is not relevant to your PR title. Suggest use another smaller PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants