On Thu, Nov 6, 2014 at 7:53 AM, Jesse Gross <je...@nicira.com> wrote:
> On Wed, Nov 5, 2014 at 6:06 PM, Pravin Shelar <pshe...@nicira.com> wrote:
>> On Wed, Nov 5, 2014 at 10:19 AM, Lori Jakab <loja...@cisco.com> wrote:
>>> On 11/5/14 12:16 AM, Pravin Shelar wrote:
>>>> On Mon, Nov 3, 2014 at 1:36 PM, Lorand Jakab <loja...@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.
ok, I think you are referring to MPLS case, I am fine with
skb_reset_mac_header() here.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
