[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160824072002.GA27254@penelope.isobedori.kobe.vergenet.net>
Date: Wed, 24 Aug 2016 09:20:11 +0200
From: Simon Horman <simon.horman@...ronome.com>
To: David Ahern <dsa@...ulusnetworks.com>
Cc: Pravin B Shelar <pshelar@...ira.com>, netdev@...r.kernel.org,
davem@...emloft.net, buytenh@...tstofly.org, ebiederm@...ssion.com,
rshearma@...cade.com, tom@...bertland.com, tgraf@...g.ch,
olivier.dugeon@...nge.com, alexander.duyck@...il.com,
roopa@...ulusnetworks.com
Subject: Re: [PATCH net-next 2/3] net: mpls: Fixups for GSO
Hi David,
On Tue, Aug 23, 2016 at 01:24:51PM -0600, David Ahern wrote:
> On 8/22/16 8:51 AM, Simon Horman wrote:
> >
> > The scheme that OvS uses so far is that mac_len denotes the number of bytes
> > from the start of the MAC header until its end. In the absence of MPLS that
> > will be the beginning of the network header. And in the presence of MPLS it
> > will be the beginning of the MPLS label stack. The network header is... the
> > network header. This allows the MAC header, MPLS label stack and network
> > header to be tracked.
>
> The neigh output functions do '__skb_pull(skb, skb_network_offset(skb))' so if mpls_xmit does not reset the network header the labels get dropped. To me this says MPLS labels can not be lumped with the mac header which leaves the only option as the outer network header.
>
> >
> > Pravin (CCed) may have different ideas but I wonder if the above scheme can
> > be preserved while also meeting the needs of your new MPLS GSO scheme if
> > you set skb_set_network_header() and skb_set_inner_network_header() in
> > net/openvswitch/actions.c:do_output().
> >
> > It may also be possible to teach OvS to use skb_set_network_header to
> > denote the beginning of the MPLS LSE and skb_set_inner_network_header to
> > denote the network header in the presence of MPLS. Which is my current
> > understanding of what you are trying to achieve. But I think its likely
> > that I misunderstand things as it seems strange to me to pretend that an
> > MPLS LSE is a network header and the outer most network header is an inner
> > network header
> >
>
> This is the only option I can see working, but open to patches showing an
> alternative.
On reflection I came to a similar conclusion.
> I would like to get it resolved this week so I can move on to gso in the
> mpls forward case.
How do you feel about implementing the do_output() idea I suggested above?
I'm happy to provide testing and review.
Powered by blists - more mailing lists