Document fast data path feature #1526
Conversation
| and a VXLAN transport ('fastdp') that leverages the Open vSwitch | ||
| kernel module to provide near-native performance. When connecting to a | ||
| new peer, the router automatically prefers the fastdp overlay under | ||
| the following conditions: |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
awh
force-pushed
the
fdp-docs
branch
2 times, most recently
from
f346149 to
e467fea
Compare
|
I have removed the information content as requested. |
| @@ -55,6 +56,20 @@ now re-use the same tools and techniques when deploying applications | |||
| as containers as we would have done when deploying them 'on metal' in | |||
| our data centre. | |||
|
|
|||
| ### <a name="optimised-traffic-transport"></a>Optimised traffic transport | |||
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
awh
force-pushed
the
fdp-docs
branch
2 times, most recently
from
c6606ce to
49c5361
Compare
|
| connections, the failure reason for failed and retrying connection | ||
| * Info - the traffic transport method, remote peer name and nickname | ||
| for (un)established connections, the failure reason for failed and | ||
| retrying connection |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
|
@dpw did you have any comments on the high level overview doc? |
I have a fairly strong idea of what a "weave router internals" doc should look like, as I was planning to write one as noted in my "things still to do" list on the fastdp PR. But I appreciate that you had to figure stuff out as you went along, and I don't see any harm in having that written down. Your doc might be quite far from what I had in mind though, so I'm not sure I will have much useful feedback. If you want to collaborate to put together a comprehensive doc, we can work on that. Or not. Either is fine by me. In the former case, I'd suggest splitting the user-facing documentation part out onto a separate PR so we can get that merged promptly. |
|
I've pulled the overview out of this PR; only updates to the user facing documentation remain. |
Document fast data path feature Fixes #1526.
This is a replacement for #1510 that is targeted against master.