All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Danilov <littlesmilingcloud@gmail.com>
To: Ido Schimmel <idosch@nvidia.com>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	David Ahern <dsahern@kernel.org>, Simon Horman <horms@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 00/10] tunnels: add core and gre drop reasons
Date: Sat, 26 Sep 2026 02:11:49 +0300	[thread overview]
Message-ID: <20260925231151.542109-1-littlesmilingcloud@gmail.com> (raw)
In-Reply-To: <20260923141923.GA2841095@shredder>

On Wed, Sep 23, 2026 at 05:19:23PM +0300, Ido Schimmel wrote:
> On Wed, Sep 23, 2026 at 01:14:57AM +0300, Anton Danilov wrote:
> > This series covers the generic paths shared by ipip, sit, gre and their
> > IPv6 counterparts, plus the GRE specific code, in both directions.
> > A later series will do the same for geneve, bareudp, fou and the
> > remaining IP in IP drivers.
>
> Please only annotate drivers that you are familiar with, using and can
> test. Otherwise it's a burden on the reviewer and potentially useless
> code churn that will make it harder to backport future fixes.

Understood. I will drop that sentence from the cover letter.

> GRE_CSUM looks fine as I'm not aware of other tunnels that have a
> dedicated checksum, but GRE_INVALID_HDR and GRE_TUNNEL_NOT_FOUND should
> be renamed to something more generic (e.g., TUNNEL_INVALID_HDR and
> TUNNEL_NOT_FOUND) so that they could be reused across drivers and
> replace the existing VXLAN ones. Note that you don't need the drop
> reason to encode the tunnel name in order to know which tunnel driver
> dropped the packet.

OK. In v5 a new patch will rename VXLAN_INVALID_HDR and
VXLAN_VNI_NOT_FOUND to TUNNEL_INVALID_HDR and TUNNEL_NOT_FOUND, the way
VXLAN_NO_REMOTE became NO_TX_TARGET, and the GRE patches will use the
new names. To keep the naming consistent, I will also rename the TNL_*
reasons this series adds to TUNNEL_*.

> > Patch 4 adds __iptunnel_pull_header_reason(), because
> > __iptunnel_pull_header() reports a packet too short to pull as -ENOMEM,
> > the same as an allocation failure, and ip6_gre calls it for every GRE
> > packet, before the tunnel lookup.
>
> The series is inconsistent about this and returns different reasons
> (HDR_TRUNC / PKT_TOO_SMALL) for the same condition. I suggest that you
> convert pskb_may_pull() to pskb_may_pull_reason() and return its reason
> instead of HDR_TRUNC.

Will do. The WCCP check in gre_parse_header() uses skb_header_pointer(),
which only fails on a short packet, so it will return PKT_TOO_SMALL.

Thanks for the review!


      reply	other threads:[~2026-09-25 23:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 22:14 [PATCH net-next v4 00/10] tunnels: add core and gre drop reasons Anton Danilov
2026-09-22 22:14 ` [PATCH net-next v4 01/10] ip_tunnel: add drop reasons to the generic RX path Anton Danilov
2026-09-22 22:14 ` [PATCH net-next v4 02/10] ip6_tunnel: " Anton Danilov
2026-09-22 22:15 ` [PATCH net-next v4 03/10] gre: make gre_parse_header() report a drop reason Anton Danilov
2026-09-23 14:59   ` Ido Schimmel
2026-09-25 23:12     ` Anton Danilov
2026-09-22 22:15 ` [PATCH net-next v4 04/10] ip_tunnel: add __iptunnel_pull_header_reason() Anton Danilov
2026-09-23 15:41   ` Ido Schimmel
2026-09-25 23:12     ` Anton Danilov
2026-09-28  6:46       ` Ido Schimmel
2026-09-22 22:15 ` [PATCH net-next v4 05/10] ip_gre: add drop reasons to the RX path Anton Danilov
2026-09-22 22:15 ` [PATCH net-next v4 06/10] ip6_gre: " Anton Danilov
2026-09-22 22:15 ` [PATCH net-next v4 07/10] ip_tunnel: add drop reasons to the transmit path Anton Danilov
2026-09-23 15:53   ` Ido Schimmel
2026-09-22 22:15 ` [PATCH net-next v4 08/10] ip_gre: " Anton Danilov
2026-09-22 22:15 ` [PATCH net-next v4 09/10] ip6_gre: make prepare_ip6gre_xmit_other() void Anton Danilov
2026-09-22 22:15 ` [PATCH net-next v4 10/10] ip6_tunnel: add drop reasons to the transmit path Anton Danilov
2026-09-23 14:19 ` [PATCH net-next v4 00/10] tunnels: add core and gre drop reasons Ido Schimmel
2026-09-25 23:11   ` Anton Danilov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260925231151.542109-1-littlesmilingcloud@gmail.com \
    --to=littlesmilingcloud@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.