On Sat, Feb 27, 2016 at 12:54 PM, Tom Herbert <t...@herbertland.com> wrote:
> On Sat, Feb 27, 2016 at 11:31 AM, Jiri Benc <jb...@redhat.com> wrote:
>> On Fri, 26 Feb 2016 15:51:29 -0800, Tom Herbert wrote:
>>> I don't think this is right. VXLAN-GPE is a separate protocol than
>>> VXLAN, they are not compatible on the wire and don't share flags or
>>> fields (for instance GPB uses bits in VXLAN that hold the next
>>> protocol in VXLAN-GPE). Neither is there a VXLAN_F_GPE flag defined in
>>> VXLAN to differentiate the two. So VXLAN-GPE would be used on a
>>> different port
>>
>> Yes, and that's exactly what this patchset does. If there's the
>> VXLAN_F_GPE flag defined while creating the interface, the used UDP
>> port defaults to the VXLAN-GPE UDP port (but can be overriden) and the
>> driver expects that all packets received are VXLAN-GPE.
>>
>> Note also that you can't define both GPE and GBP together, because as
>> you noted, they're not compatible. The driver correctly refuses such
>> combination.
>>
> Yes, but RCO has not been specified for VXLAN-GPE either so the patch
> does not correctly refuse setting those two together. Inevitably
> though, those and other extensions will defined for VXLAN-GPE and new
> ones for VXLAN. Again, the protocols are fundamentally incompatible,
> so instead of trying to enforce each valid combination at
> configuration or performing multiple checks for flavor each time we
> look at a packet, it seems easier to split the parsing with at most
> one check for the protocol variant. For instance in
> vxlan_udp_encap_recv just do:
>
> if (vs->flags & VXLAN_F_GPE)
> if (!vxlan_parse_gpe_hdr(&unparsed, skb, vs->flags))
> goto drop;
> else
> if (!vxlan_parse_gpe(&unparsed, skb, vs->flags))
> goto drop;
>
I meant
if (vs->flags & VXLAN_F_GPE)
if (!vxlan_parse_gpe_hdr(&unparsed, skb, vs->flags))
goto drop;
else
if (!vxlan_parse_hdr(&unparsed, skb, vs->flags))
goto drop;
>
> And then move REMCSUM and GPB and other protocol specific checks to
> the right function.
>
> Tom
