Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220706160021.10710-1-matthias.may@westermo.com>
 <CAHsH6GsN=kykC32efTWhHKSPqi8Qn3HYgRursSSY2JiFf2hijw@mail.gmail.com> <45a19551-6004-2453-2f16-a7af5d5c0a59@westermo.com>
In-Reply-To: <45a19551-6004-2453-2f16-a7af5d5c0a59@westermo.com>
From:   Eyal Birger <eyal.birger@gmail.com>
Date:   Thu, 7 Jul 2022 12:38:46 +0300
Message-ID: <CAHsH6GtyXozwURA17DANjmmEVNRXTKZ-HASD6RhzisJ-+LZ=8Q@mail.gmail.com>
Subject: Re: [PATCH net-next v2] ip_tunnel: allow to inherit from VLAN
 encapsulated IP frames
To:     Matthias May <matthias.may@westermo.com>
Cc:     netdev@vger.kernel.org, davem@davemloft.net,
        yoshfuji@linux-ipv6.org, dsahern@kernel.org, edumazet@google.com,
        kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jul 7, 2022 at 10:44 AM Matthias May <matthias.may@westermo.com> wrote:
>
> On 7/6/22 19:24, Eyal Birger wrote:
> >
> > Hi,
> >
> > On Wed, Jul 6, 2022 at 7:54 PM Matthias May <matthias.may@westermo.com <mailto:matthias.may@westermo.com>> wrote:
> >
> >     The current code allows to inherit the TOS, TTL, DF from the payload
> >     when skb->protocol is ETH_P_IP or ETH_P_IPV6.
> >     However when the payload is VLAN encapsulated (e.g because the tunnel
> >     is of type GRETAP), then this inheriting does not work, because the
> >     visible skb->protocol is of type ETH_P_8021Q.
> >
> >     Add a check on ETH_P_8021Q and subsequently check the payload protocol.
> >
> >     Signed-off-by: Matthias May <matthias.may@westermo.com <mailto:matthias.may@westermo.com>>
> >     ---
> >     v1 -> v2:
> >       - Add support for ETH_P_8021AD as suggested by Jakub Kicinski.
> >     ---
> >       net/ipv4/ip_tunnel.c | 22 ++++++++++++++--------
> >       1 file changed, 14 insertions(+), 8 deletions(-)
> >
> >     diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> >     index 94017a8c3994..bdcc0f1e83c8 100644
> >     --- a/net/ipv4/ip_tunnel.c
> >     +++ b/net/ipv4/ip_tunnel.c
> >     @@ -648,6 +648,13 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
> >              u8 tos, ttl;
> >              __be32 dst;
> >              __be16 df;
> >     +       __be16 *payload_protocol;
> >     +
> >     +       if (skb->protocol == htons(ETH_P_8021Q) ||
> >     +           skb->protocol == htons(ETH_P_8021AD))
> >     +               payload_protocol = (__be16 *)(skb->head + skb->network_header - 2);
> >     +       else
> >     +               payload_protocol = &skb->protocol;
> >
> >
> > Maybe it's better to use skb_protocol(skb, true) here instead of open
> > coding the vlan parsing?
> >
> > Eyal
>
> Hi Eyal
> I've looked into using skb_protocol(skb, true).
> If skip_vlan is set to true, wouldn't it make sense to use vlan_get_protocol(skb) directly?

Since it's inlined i don't think it makes a practical difference.
Personally I'd find it more readable to use skb_protocol() here because
VLANs are the less expected path, and the change is basically to ignore
them.

Eyal.