diff mbox series

[net-next,1/2] net: typhoon: implement ndo_features_check method

Message ID 20220203180227.3751784-2-eric.dumazet@gmail.com (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series net: remove two MAX_SKB_FRAGS dependencies | expand

Checks

Context Check Description
netdev/tree_selection success Clearly marked for net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix success Link
netdev/cover_letter success Series has a cover letter
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 2 this patch: 2
netdev/cc_maintainers warning 1 maintainers not CCed: dave@thedillows.org
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 2 this patch: 2
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 38 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Eric Dumazet Feb. 3, 2022, 6:02 p.m. UTC 
From: Eric Dumazet <edumazet@google.com>

Instead of disabling TSO if MAX_SKB_FRAGS > 32, implement
ndo_features_check() method for this driver.

If skb has more than 32 frags, use the following heuristic:

1) force GSO for gso packets.
2) Otherwise force linearization.

Most locally generated packets will use a small number
of fragments anyway.

For forwarding workloads, we can limit gro_max_size at ingress,
we might also implement gro_max_segs if needed.

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 drivers/net/ethernet/3com/typhoon.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

Comments

Jakub Kicinski Feb. 5, 2022, 3:52 a.m. UTC | #1 
On Thu,  3 Feb 2022 10:02:26 -0800 Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> Instead of disabling TSO if MAX_SKB_FRAGS > 32, implement
> ndo_features_check() method for this driver.
> 
> If skb has more than 32 frags, use the following heuristic:
> 
> 1) force GSO for gso packets.
> 2) Otherwise force linearization.
> 
> Most locally generated packets will use a small number
> of fragments anyway.
> 
> For forwarding workloads, we can limit gro_max_size at ingress,
> we might also implement gro_max_segs if needed.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
>  drivers/net/ethernet/3com/typhoon.c | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c
> index 8aec5d9fbfef2803c181387537300502a937caf0..67b1a1f439d841ed0ed0f620e9477607ac6e2fae 100644
> --- a/drivers/net/ethernet/3com/typhoon.c
> +++ b/drivers/net/ethernet/3com/typhoon.c
> @@ -138,11 +138,6 @@ MODULE_PARM_DESC(use_mmio, "Use MMIO (1) or PIO(0) to access the NIC. "
>  module_param(rx_copybreak, int, 0);
>  module_param(use_mmio, int, 0);
>  
> -#if defined(NETIF_F_TSO) && MAX_SKB_FRAGS > 32
> -#warning Typhoon only supports 32 entries in its SG list for TSO, disabling TSO
> -#undef NETIF_F_TSO
> -#endif
> -
>  #if TXLO_ENTRIES <= (2 * MAX_SKB_FRAGS)
>  #error TX ring too small!
>  #endif
> @@ -2261,9 +2256,27 @@ typhoon_test_mmio(struct pci_dev *pdev)
>  	return mode;
>  }
>  
> +#if MAX_SKB_FRAGS > 32
> +static netdev_features_t typhoon_features_check(struct sk_buff *skb,
> +						struct net_device *dev,
> +						netdev_features_t features)
> +{
> +	if (skb_shinfo(skb)->nr_frags > 32) {
> +		if (skb_is_gso(skb))
> +			features &= ~NETIF_F_GSO_MASK;
> +		else
> +			features &= ~NETIF_F_SG;

Should we always clear SG? If we want to make the assumption that
non-gso skbs are never this long (like the driver did before) then
we should never clear SG. If we do we risk one of the gso-generated
segs will also be longer than 32 frags.

Thought I should ask.

> +	}
> +	return features;

return vlan_features_check(skb, features) ?

> +}
> +#endif
> +
>  static const struct net_device_ops typhoon_netdev_ops = {
>  	.ndo_open		= typhoon_open,
>  	.ndo_stop		= typhoon_close,
> +#if MAX_SKB_FRAGS > 32
> +	.ndo_features_check	= typhoon_features_check,
> +#endif
>  	.ndo_start_xmit		= typhoon_start_tx,
>  	.ndo_set_rx_mode	= typhoon_set_rx_mode,
>  	.ndo_tx_timeout		= typhoon_tx_timeout,
Eric Dumazet Feb. 5, 2022, 4:26 a.m. UTC | #2 
On Fri, Feb 4, 2022 at 7:52 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu,  3 Feb 2022 10:02:26 -0800 Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Instead of disabling TSO if MAX_SKB_FRAGS > 32, implement
> > ndo_features_check() method for this driver.
> >
> > If skb has more than 32 frags, use the following heuristic:
> >
> > 1) force GSO for gso packets.
> > 2) Otherwise force linearization.
> >
> > Most locally generated packets will use a small number
> > of fragments anyway.
> >
> > For forwarding workloads, we can limit gro_max_size at ingress,
> > we might also implement gro_max_segs if needed.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > ---
> >  drivers/net/ethernet/3com/typhoon.c | 23 ++++++++++++++++++-----
> >  1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c
> > index 8aec5d9fbfef2803c181387537300502a937caf0..67b1a1f439d841ed0ed0f620e9477607ac6e2fae 100644
> > --- a/drivers/net/ethernet/3com/typhoon.c
> > +++ b/drivers/net/ethernet/3com/typhoon.c
> > @@ -138,11 +138,6 @@ MODULE_PARM_DESC(use_mmio, "Use MMIO (1) or PIO(0) to access the NIC. "
> >  module_param(rx_copybreak, int, 0);
> >  module_param(use_mmio, int, 0);
> >
> > -#if defined(NETIF_F_TSO) && MAX_SKB_FRAGS > 32
> > -#warning Typhoon only supports 32 entries in its SG list for TSO, disabling TSO
> > -#undef NETIF_F_TSO
> > -#endif
> > -
> >  #if TXLO_ENTRIES <= (2 * MAX_SKB_FRAGS)
> >  #error TX ring too small!
> >  #endif
> > @@ -2261,9 +2256,27 @@ typhoon_test_mmio(struct pci_dev *pdev)
> >       return mode;
> >  }
> >
> > +#if MAX_SKB_FRAGS > 32
> > +static netdev_features_t typhoon_features_check(struct sk_buff *skb,
> > +                                             struct net_device *dev,
> > +                                             netdev_features_t features)
> > +{
> > +     if (skb_shinfo(skb)->nr_frags > 32) {
> > +             if (skb_is_gso(skb))
> > +                     features &= ~NETIF_F_GSO_MASK;
> > +             else
> > +                     features &= ~NETIF_F_SG;
>
> Should we always clear SG? If we want to make the assumption that
> non-gso skbs are never this long (like the driver did before) then
> we should never clear SG. If we do we risk one of the gso-generated
> segs will also be longer than 32 frags.

If I read the comment (deleted in this patch), it seems the 32 limits
is about TSO only ?

#warning Typhoon only supports 32 entries in its SG list for TSO, disabling TSO

This is why I chose this implementation.

>
> Thought I should ask.
>
> > +     }
> > +     return features;
>
> return vlan_features_check(skb, features) ?

Hmm... not sure why we duplicate vlan_features_check() &
vxlan_features_check() in all ndo_features_check() handlers :/

>
> > +}
> > +#endif
> > +
> >  static const struct net_device_ops typhoon_netdev_ops = {
> >       .ndo_open               = typhoon_open,
> >       .ndo_stop               = typhoon_close,
> > +#if MAX_SKB_FRAGS > 32
> > +     .ndo_features_check     = typhoon_features_check,
> > +#endif
> >       .ndo_start_xmit         = typhoon_start_tx,
> >       .ndo_set_rx_mode        = typhoon_set_rx_mode,
> >       .ndo_tx_timeout         = typhoon_tx_timeout,
>
Jakub Kicinski Feb. 5, 2022, 4:34 a.m. UTC | #3 
On Fri, 4 Feb 2022 20:26:58 -0800 Eric Dumazet wrote:
> > Should we always clear SG? If we want to make the assumption that
> > non-gso skbs are never this long (like the driver did before) then
> > we should never clear SG. If we do we risk one of the gso-generated
> > segs will also be longer than 32 frags.  
> 
> If I read the comment (deleted in this patch), it seems the 32 limits
> is about TSO only ?
> 
> #warning Typhoon only supports 32 entries in its SG list for TSO, disabling TSO
> 
> This is why I chose this implementation.

Right, sort of my point - to stay true to old code we don't need to
worry about SG ? The old code didn't..

> > Thought I should ask.
> >  
> > > +     }
> > > +     return features;  
> >
> > return vlan_features_check(skb, features) ?  
> 
> Hmm... not sure why we duplicate vlan_features_check() &
> vxlan_features_check() in all ndo_features_check() handlers :/

I was wondering as well. I can only speculate.. :S
Eric Dumazet Feb. 5, 2022, 4:38 a.m. UTC | #4 
On Fri, Feb 4, 2022 at 8:34 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 4 Feb 2022 20:26:58 -0800 Eric Dumazet wrote:
> > > Should we always clear SG? If we want to make the assumption that
> > > non-gso skbs are never this long (like the driver did before) then
> > > we should never clear SG. If we do we risk one of the gso-generated
> > > segs will also be longer than 32 frags.
> >
> > If I read the comment (deleted in this patch), it seems the 32 limits
> > is about TSO only ?
> >
> > #warning Typhoon only supports 32 entries in its SG list for TSO, disabling TSO
> >
> > This is why I chose this implementation.
>
> Right, sort of my point - to stay true to old code we don't need to
> worry about SG ? The old code didn't..

I misread your comment.

I thought you suggested to always clear SG, regardless of GSO or not, as in

       if (skb_shinfo(skb)->nr_frags > 32) {
               if (skb_is_gso(skb))
                       features &= ~NETIF_F_GSO_MASK;
               features &= ~NETIF_F_SG;
       }


>
> > > Thought I should ask.
> > >
> > > > +     }
> > > > +     return features;
> > >
> > > return vlan_features_check(skb, features) ?
> >
> > Hmm... not sure why we duplicate vlan_features_check() &
> > vxlan_features_check() in all ndo_features_check() handlers :/
>
> I was wondering as well. I can only speculate.. :S
diff mbox series

Patch

diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c
index 8aec5d9fbfef2803c181387537300502a937caf0..67b1a1f439d841ed0ed0f620e9477607ac6e2fae 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -138,11 +138,6 @@  MODULE_PARM_DESC(use_mmio, "Use MMIO (1) or PIO(0) to access the NIC. "
 module_param(rx_copybreak, int, 0);
 module_param(use_mmio, int, 0);
 
-#if defined(NETIF_F_TSO) && MAX_SKB_FRAGS > 32
-#warning Typhoon only supports 32 entries in its SG list for TSO, disabling TSO
-#undef NETIF_F_TSO
-#endif
-
 #if TXLO_ENTRIES <= (2 * MAX_SKB_FRAGS)
 #error TX ring too small!
 #endif
@@ -2261,9 +2256,27 @@  typhoon_test_mmio(struct pci_dev *pdev)
 	return mode;
 }
 
+#if MAX_SKB_FRAGS > 32
+static netdev_features_t typhoon_features_check(struct sk_buff *skb,
+						struct net_device *dev,
+						netdev_features_t features)
+{
+	if (skb_shinfo(skb)->nr_frags > 32) {
+		if (skb_is_gso(skb))
+			features &= ~NETIF_F_GSO_MASK;
+		else
+			features &= ~NETIF_F_SG;
+	}
+	return features;
+}
+#endif
+
 static const struct net_device_ops typhoon_netdev_ops = {
 	.ndo_open		= typhoon_open,
 	.ndo_stop		= typhoon_close,
+#if MAX_SKB_FRAGS > 32
+	.ndo_features_check	= typhoon_features_check,
+#endif
 	.ndo_start_xmit		= typhoon_start_tx,
 	.ndo_set_rx_mode	= typhoon_set_rx_mode,
 	.ndo_tx_timeout		= typhoon_tx_timeout,