-
Notifications
You must be signed in to change notification settings - Fork 3
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
What model do existing pacing offloads supported by NICs use? #45
Comments
(I'm really hoping the above experience was really just a nightmare I was having. This Issue is to basically find out whether that's the case.) |
The first one is the model we're going with. |
That doesn't answer my question, though. I'm asking, what model do the NICs currently use? |
By the way, I found what I was reading before, here's a link: https://docs.nvidia.com/networking/display/VMAv875/Advanced+Features#AdvancedFeatures-PacketPacing They describe an API that smells like a global pacing rate for the whole interface, which isn't what we want; then they mention something called the "rivermax library" for more "advanced" pacing, but it's a dead link. |
Both models should be possible, we have work in DPDK with the second model, here are some references: |
Pacing can be done two ways: either each packet is posted to the NIC with a timestamp (which feels like what we ideally want to have), or you can plub a rate limit to the nic, post packets without any metadata (or maybe with a flow ID to match them up with a per-flow plumbed rate limit), and the NIC decides when to send each packet.
I did some prelim research on this topic a while back and was surprised to read in some docs (IIRC from Mellanox) that the second model above is used.
We probably want the first model, but if NICs are already doing the second model that will be an ugly ask.
The text was updated successfully, but these errors were encountered: