You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Network datapaths typically handle packets in two different ways:
When it's a new "flow", identified by it's 5-tuple (src/dst MAC, src/dst IP, L4 port), datapaths typically need extra processing, such as access control, etc. Then, the "flow" is typically cached in some way.
When the packet is part of an already existing "flow", it's common to just execute the cached actions.
This difference is specially relevant in OpenvSwitch.
Based on this, the proposal is for the Server workload to support something like connections/sec option and have it create a new connection when needed. That way we would stress both "paths". A possible way to implement this would be to have the server reserve a big range of ports and then the client could round-robin between them.
The text was updated successfully, but these errors were encountered:
If I specify connections/sec of 5, I'd open a connection, send traffic for 200 ms (or until 200 ms after I attempted to open the connection), close it, and then round-robin to the next port?
Network datapaths typically handle packets in two different ways:
This difference is specially relevant in OpenvSwitch.
Based on this, the proposal is for the Server workload to support something like
connections/sec
option and have it create a new connection when needed. That way we would stress both "paths". A possible way to implement this would be to have the server reserve a big range of ports and then the client could round-robin between them.The text was updated successfully, but these errors were encountered: