On Wed, Nov 5, 2014 at 8:00 PM, Tom Herbert <therb...@google.com> wrote: > On Wed, Nov 5, 2014 at 9:50 AM, Joe Stringer <joestrin...@nicira.com> wrote: >> >> On 5 November 2014 04:38, Or Gerlitz <gerlitz...@gmail.com> wrote: >>> >>> On Tue, Nov 4, 2014 at 11:56 PM, Joe Stringer <joestrin...@nicira.com> >>> wrote: >>> > Most NICs that report NETIF_F_GSO_UDP_TUNNEL support VXLAN, and not other >>> > UDP-based encapsulation protocols where the format and size of the header >>> > may >>> > differ. This patch series implements ndo_gso_check() for these NICs, >>> > restricting the GSO handling to something that looks and smells like >>> > VXLAN. >>> > >>> > Implementation shamelessly stolen from Tom Herbert (with minor fixups): >>> > http://thread.gmane.org/gmane.linux.network/332428/focus=333111 >>> >>> >>> Hi Joe, >>> >>> 1st, thanks for picking this task...2nd, for drivers that currently >>> support only pure VXLAN, I don't see the point >>> to replicate the helper suggested by Tom (good catch on the size check >>> to be 16 and not 12) four times and who know how more in the future. >>> Let's just have one generic helper and make the mlx4/be/fm10k/benet >>> drivers to have it as their ndo, OK? >> >> >> Thanks for taking a look. >> >> I had debated whether to do this or not as the actual support on each NIC >> may differ, and each implementation may morph over time to match these >> capabilities better. Obviously the vendors will know better than me on this, >> so I'm posing this series to prod them for more information. At this point >> I've had just one maintainer come back and confirm that this helper is a >> good fit for their hardware, so I'd like to confirm that multiple drivers >> will use a ndo_gso_check_vxlan_helper() function before I go and create it. > > > Thanks for implementing this fix! > > Personally, I would rather not have the helper. This is already a > small number of drivers, and each driver owner should consider what > limitations are of their device and try to enable to allow the maximum > number of use cases possible. I'm also hoping that new devices will > implement the more generic mechanism so that VXLAN is just one > supported protocol.
but fact is that the proposed patch series has the --same-- helper for four drivers, so why not start with a that limited helper which would be picked up by these drivers and we'll take it from there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
