-
Notifications
You must be signed in to change notification settings - Fork 1
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
Acquire neighboring router MAC dynamically #619
Changes from 1 commit
547e5a3
8cae391
818d49d
1e8379e
722a29d
438850f
77bb2f1
cde58a9
630ea2d
0ebf723
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -86,6 +86,9 @@ void dp_process_event_link_msg(struct rte_mbuf *m) | |
|
||
port->link_status = status; | ||
DPS_LOG_INFO("PF link state changed", DP_LOG_LINKSTATE(port->link_status), DP_LOG_PORT(port)); | ||
|
||
if (status == RTE_ETH_LINK_UP) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should move this part to So in a nutshell:
with this approach, we wouldnt at least worsen the situation in current code. Interrupt thread enqueuing together with main thread to monitoring queue can be addressed separately as it was not caused by this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I moved the indicated code away from worker thread to the "interrupt" thread (the one where timer fires). I think this should be enough, but if we only ever want to call the MAC retrieval code from one thread (the interrupt thread) and not the main thread, it would require removing the ability to "get the MAC immediately" in the init phase, thus always waiting at least a second for it. Which I do not believe is needed as the real problem here was the worker doing unnecessary stuff, which is fixed now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also think that the change is sufficient for this PR. |
||
dp_acquire_neigh_mac(port); | ||
} | ||
|
||
// Flow-aging message - sent periodically to age-out conntracked flows | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have some combinations which do not make sense with the newly introduced flags ?
Like, if I set
pf1-proxy
then I need to setpf1-proxy-vf
as well ? and If I set multiport-eswitch, I would needpf1-proxy-*
switches and if they are not set then I can not operate meaningfully ?If so, can we document these dependencies ? and enforce during command line argument parsing with meaningful hints returned ?
Also in the documentation, maybe an example dpservice-bin command including all the command line parameters for a simple mpesw operation ?
Or maybe I overlooked it in the documentation ? Otherwise it is not so clear now, how to make mpesw work and which parameters are needed to make it work. At least to me.
These command line arguments are supposed to be generated by
prepare.sh
right ? but still showcasing in an example which parameters needed for dpservice-bin to operate successfully in mpesw mode, would be helpful and how (with which parameters) am I supposed to call prepare.sh if I want to operate in mpesw mode ?