From: Peilin Ye <[email protected]>
Hi all,
This patchset depends on these fixes [1]. Since o_seqno is now atomic_t,
we can always turn on NETIF_F_LLTX for [IP6]GRE[TAP] devices, since we no
longer need the TX lock (&txq->_xmit_lock).
We could probably do the same thing to [IP6]ERSPAN devices as well, but
I'm not familiar with them yet. For example, ERSPAN devices are
initialized as |= GRE_FEATURES in erspan_tunnel_init(), but I don't see
IP6ERSPAN devices being initialized as |= GRE6_FEATURES. Please suggest
if I'm missing something, thanks!
[1] https://lore.kernel.org/netdev/[email protected]/
Thanks,
Peilin Ye (2):
ip_gre: Make GRE and GRETAP devices always NETIF_F_LLTX
ip6_gre: Make IP6GRE and IP6GRETAP devices always NETIF_F_LLTX
net/ipv4/ip_gre.c | 50 ++++++++++++++++++++--------------------------
net/ipv6/ip6_gre.c | 34 ++++++++++++-------------------
2 files changed, 35 insertions(+), 49 deletions(-)
--
2.20.1
From: Peilin Ye <[email protected]>
Recently we made o_seqno atomic_t. Stop special-casing TUNNEL_SEQ, and
always mark IP6GRE[TAP] devices as NETIF_F_LLTX, since we no longer need
the TX lock (&txq->_xmit_lock).
Signed-off-by: Peilin Ye <[email protected]>
---
net/ipv6/ip6_gre.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 5136959b3dc5..4e37f7c29900 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -382,11 +382,6 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct net *net,
goto failed_free;
ip6gre_tnl_link_config(nt, 1);
-
- /* Can use a lockless transmit, unless we generate output sequences */
- if (!(nt->parms.o_flags & TUNNEL_SEQ))
- dev->features |= NETIF_F_LLTX;
-
ip6gre_tunnel_link(ign, nt);
return nt;
@@ -1445,26 +1440,23 @@ static void ip6gre_tunnel_setup(struct net_device *dev)
static void ip6gre_tnl_init_features(struct net_device *dev)
{
struct ip6_tnl *nt = netdev_priv(dev);
+ __be16 flags;
- dev->features |= GRE6_FEATURES;
+ dev->features |= GRE6_FEATURES | NETIF_F_LLTX;
dev->hw_features |= GRE6_FEATURES;
- if (!(nt->parms.o_flags & TUNNEL_SEQ)) {
- /* TCP offload with GRE SEQ is not supported, nor
- * can we support 2 levels of outer headers requiring
- * an update.
- */
- if (!(nt->parms.o_flags & TUNNEL_CSUM) ||
- nt->encap.type == TUNNEL_ENCAP_NONE) {
- dev->features |= NETIF_F_GSO_SOFTWARE;
- dev->hw_features |= NETIF_F_GSO_SOFTWARE;
- }
+ flags = nt->parms.o_flags;
- /* Can use a lockless transmit, unless we generate
- * output sequences
- */
- dev->features |= NETIF_F_LLTX;
- }
+ /* TCP offload with GRE SEQ is not supported, nor can we support 2
+ * levels of outer headers requiring an update.
+ */
+ if (flags & TUNNEL_SEQ)
+ return;
+ if (flags & TUNNEL_CSUM && nt->encap.type != TUNNEL_ENCAP_NONE)
+ return;
+
+ dev->features |= NETIF_F_GSO_SOFTWARE;
+ dev->hw_features |= NETIF_F_GSO_SOFTWARE;
}
static int ip6gre_tunnel_init_common(struct net_device *dev)
--
2.20.1
On Thu, 21 Apr 2022 15:43:42 -0700 Peilin Ye wrote:
> This patchset depends on these fixes [1]. Since o_seqno is now atomic_t,
> we can always turn on NETIF_F_LLTX for [IP6]GRE[TAP] devices, since we no
> longer need the TX lock (&txq->_xmit_lock).
LGTM, thanks, but please repost on Thu / Fri. The fixes make their way
into net-next on Thu so until then we can't apply.
> We could probably do the same thing to [IP6]ERSPAN devices as well, but
> I'm not familiar with them yet. For example, ERSPAN devices are
> initialized as |= GRE_FEATURES in erspan_tunnel_init(), but I don't see
> IP6ERSPAN devices being initialized as |= GRE6_FEATURES. Please suggest
> if I'm missing something, thanks!
Probably good to CC William when you repost.
Hi Jakub,
On Mon, Apr 25, 2022 at 11:02:59AM -0700, Jakub Kicinski wrote:
> On Thu, 21 Apr 2022 15:43:42 -0700 Peilin Ye wrote:
> > This patchset depends on these fixes [1]. Since o_seqno is now atomic_t,
> > we can always turn on NETIF_F_LLTX for [IP6]GRE[TAP] devices, since we no
> > longer need the TX lock (&txq->_xmit_lock).
>
> LGTM, thanks, but please repost on Thu / Fri. The fixes make their way
> into net-next on Thu so until then we can't apply.
Thanks for the review!
> > We could probably do the same thing to [IP6]ERSPAN devices as well, but
> > I'm not familiar with them yet. For example, ERSPAN devices are
> > initialized as |= GRE_FEATURES in erspan_tunnel_init(), but I don't see
> > IP6ERSPAN devices being initialized as |= GRE6_FEATURES. Please suggest
> > if I'm missing something, thanks!
>
> Probably good to CC William when you repost.
Sure, I will resend then.
Thanks,
Peilin Ye