On 11/6/14 7:17 PM, Pravin Shelar wrote:
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.
I'll leave it as-is then.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
