Skip to content
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

Worker fixes #175

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Worker fixes #175

wants to merge 6 commits into from

Conversation

rjarry
Copy link
Collaborator

@rjarry rjarry commented Mar 4, 2025

No description provided.

rjarry added 4 commits March 4, 2025 22:24
Nexthop events should go next to nexthop definitions in gr_nexthop.h.
Move interface events before API message definitions.

Signed-off-by: Robin Jarry <[email protected]>
If that thread cannot be started, grout will not function.

Signed-off-by: Robin Jarry <[email protected]>
Moving one RXQ from one worker to another is only safe if the
originating/source worker has stopped polling the RXQ before allowing
the target/destination worker to starting polling it.

Currently, after updating the queue maps of the source and target
workers, we reload *all* workers without enforcing any order or
operations. The target worker may very well be reloaded before the
source one leading to concurrent polling of the moved RXQ by two
worker threads.

Fix this by always reloading the source worker first to ensure that it
has given up on the RXQ, before reloading the target worker. It also has
the side effect of only requiring to reload these two workers and not
all of them.

Signed-off-by: Robin Jarry <[email protected]>
(1 << n) evaluates to a 32 bit signed integer by default. Use GR_BIT64
which properly casts to uint64_t.

Signed-off-by: Robin Jarry <[email protected]>
@rjarry rjarry requested a review from david-marchand March 5, 2025 10:11
Instead of trying to be a smart ass about memory ordering types, always
use the safest memory_order_seq_cst (Sequentially consistent ordering)
which is the one used by simple atomic_load() and atomic_store() macros.

If we ever encounter some performance issues, we can reconsider each
individual atomic operation to see if a more precise/relaxed memory
ordering would help.

For the record, on x86, using atomic_store() and atomic_load() on
_Atomic() variables is redundant and will not necessarily induce
explicit memory barrier/fence instructions.

Link: https://en.cppreference.com/w/c/atomic/memory_order
Link: https://en.cppreference.com/w/c/language/atomic
Signed-off-by: Robin Jarry <[email protected]>
The port_queue_assign function code is rather obscure. Add comments to
explain what is done and why.

Signed-off-by: Robin Jarry <[email protected]>
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.

1 participant