Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
From: Jesse Gross <jesse@kernel.org>
Date: 2015-12-01 01:28:33
On Mon, Nov 30, 2015 at 5:02 PM, Tom Herbert [off-list ref] wrote:
On Mon, Nov 30, 2015 at 4:25 PM, Jesse Gross [off-list ref] wrote:quoted
On Sun, Nov 29, 2015 at 7:21 PM, David Miller [off-list ref] wrote:quoted
From: Tom Herbert <redacted> Date: Mon, 23 Nov 2015 13:53:44 -0800quoted
The bad effect of this model is that it is encourages HW vendors to continue implement HW protocol specific support for encapsulations, we get so much more benefit if they implement protocol generic mechanisms.+1Regardless of what happens in the future, I think the main question is how this relates to the code that is currently present in the tree. We already have NDOs for VXLAN offloading, which is about as protocol specific as you can get. In my mind, this series is strictly an improvement to what is already there - it pulls all hardware offloading code out of the various protocol implementations and VXLAN out of the driver interface. That seems like a pretty nice cleanup to me.Jesse, I don't think VXLAN is a good role model here. Consider that Cisco now is basically trying to obsolete VXLAN in favor of VXLAN-GPE. VXLAN-GPE is not compatible with VXLAN, so in order to get the same HW offloads talking VXLAN-GPE users will probably need to swap out their HW. If I am misreading this situation let me know, but to me this doesn't sound like a model the stack should endorse.
The point that I was trying to make is that we already have VXLAN offloading in the stack and it exists there today. The way that it is implemented is about as protocol specific as you can get - protocols need to know about offloads and drivers need to know about protocols. I would like to find a way to at least make the code cleaner while we wait for hardware to evolve. Based on what we can do today, I see only two real choices: do some refactoring to clean up the stack a bit or remove the existing VXLAN offloading altogether. I think this series is trying to do the former and the result is that the stack is cleaner after than before. That seems like a good thing.