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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev