[ovs-dev] [PATCH v6 3/3] datapath: add layer 3 flow/port support

Jesse Gross jesse at nicira.com
Thu Nov 6 15:53:53 UTC 2014


On Wed, Nov 5, 2014 at 6:06 PM, Pravin Shelar <pshelar at nicira.com> wrote:
> On Wed, Nov 5, 2014 at 10:19 AM, Lori Jakab <lojakab at cisco.com> wrote:
>> On 11/5/14 12:16 AM, Pravin Shelar wrote:
>>> On Mon, Nov 3, 2014 at 1:36 PM, Lorand Jakab <lojakab at cisco.com> wrote:
>>>> +static int pop_eth(struct sk_buff *skb)
>>>> +{
>>>> +       skb_pull_rcsum(skb, ETH_HLEN);
>>>> +       skb_reset_mac_header(skb);
>>>> +       skb->mac_len -= ETH_HLEN;
>>>> +
>>>> +       return 0;
>>>> +}
>>>> +
>>>
>>> We should pop mac header offset too(skb_pop_mac_header()). So that GSO
>>> works for l3 packet.
>>
>>
>> We had a discussion with Jesse about the possibility of supporting
>> MAC-in-MAC encapsulations, where you could have more than one pop_eth() one
>> after the other.  See the thread here:
>> http://openvswitch.org/pipermail/dev/2014-August/043379.html
>>
>> Can we have both GSO working and not conflicting with the above?
>>
>
> skb_pop_mac_header() just set mac header to mpls header. I am not sure
> why is that problem.
> If you look at __skb_udp_tunnel_segment() or equivalent gre handler,
> you will see that it expect inner mac header set correctly, So if you
> pop eth header we need to update mac header offset.

skb_pop_mac_header() and skb_reset_mac_header() are both acting on the
same field, so it is being updated here. The latter will set it to
exactly the current state of the packet whereas the former sets it to
the network header, which is probably what we have (given that we are
trying to get to the network header) but it seems more likely to
potentially introduce corner cases.



More information about the dev mailing list