| Message ID | 20190918072517.16037-3-steffen.klassert@secunet.com |
|---|---|
| State | RFC |
| Delegated to: | David Miller |
| Headers | show |
| Series | None | expand |
On Wed, Sep 18, 2019 at 3:25 AM Steffen Klassert <steffen.klassert@secunet.com> wrote: > > This adds a new NETIF_F_GRO_LIST feature flag. I will be used > to configure listfyed GRO what will be implemented with some > followup paches. This should probably simultaneously introduce SKB_GSO_FRAGLIST as well as a BUILD_BUG_ON in net_gso_ok. Please also in the commit describe the constraints of skbs that have this type. If I'm not mistaken, an skb with either gso_size linear data or one gso_sized frag, followed by a frag_list of the same. With the exception of the last frag_list member, whose mss may be less than gso_size. This will help when reasoning about all the types of skbs we may see at segmentation, as we recently had to do [1] Minor nit: I think it's listified, not listifyed. [1] https://lore.kernel.org/netdev/CA+FuTSfVsgNDi7c=GUU8nMg2hWxF2SjCNLXetHeVPdnxAW5K-w@mail.gmail.com/ > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> > --- > include/linux/netdev_features.h | 2 ++ > net/core/ethtool.c | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h > index 4b19c544c59a..1b6baa1b6fe9 100644 > --- a/include/linux/netdev_features.h > +++ b/include/linux/netdev_features.h > @@ -80,6 +80,7 @@ enum { > > NETIF_F_GRO_HW_BIT, /* Hardware Generic receive offload */ > NETIF_F_HW_TLS_RECORD_BIT, /* Offload TLS record */ > + NETIF_F_GRO_LIST_BIT, /* Listifyed GRO */ > > /* > * Add your fresh new feature above and remember to update > @@ -150,6 +151,7 @@ enum { > #define NETIF_F_GSO_UDP_L4 __NETIF_F(GSO_UDP_L4) > #define NETIF_F_HW_TLS_TX __NETIF_F(HW_TLS_TX) > #define NETIF_F_HW_TLS_RX __NETIF_F(HW_TLS_RX) > +#define NETIF_F_GRO_LIST __NETIF_F(GRO_LIST) > > /* Finds the next feature with the highest number of the range of start till 0. > */ > diff --git a/net/core/ethtool.c b/net/core/ethtool.c > index 6288e69e94fc..ee8d2b58c2d7 100644 > --- a/net/core/ethtool.c > +++ b/net/core/ethtool.c > @@ -111,6 +111,7 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN] > [NETIF_F_HW_TLS_RECORD_BIT] = "tls-hw-record", > [NETIF_F_HW_TLS_TX_BIT] = "tls-hw-tx-offload", > [NETIF_F_HW_TLS_RX_BIT] = "tls-hw-rx-offload", > + [NETIF_F_GRO_LIST_BIT] = "rx-gro-list", > }; > > static const char > -- > 2.17.1 >
On 2019-09-18 10:10, Willem de Bruijn wrote: > On Wed, Sep 18, 2019 at 3:25 AM Steffen Klassert > <steffen.klassert@secunet.com> wrote: >> >> This adds a new NETIF_F_GRO_LIST feature flag. I will be used >> to configure listfyed GRO what will be implemented with some >> followup paches. > > This should probably simultaneously introduce SKB_GSO_FRAGLIST as well > as a BUILD_BUG_ON in net_gso_ok. > > Please also in the commit describe the constraints of skbs that have > this type. If I'm not mistaken, an skb with either gso_size linear > data or one gso_sized frag, followed by a frag_list of the same. With > the exception of the last frag_list member, whose mss may be less than > gso_size. This will help when reasoning about all the types of skbs we > may see at segmentation, as we recently had to do [1] > Would it be preferrable to allow any size skbs for the listification. Since the original skbs are being restored, single gso_size shoudln't be a constraint here.
On Wed, Sep 18, 2019 at 12:10:31PM -0400, Willem de Bruijn wrote: > On Wed, Sep 18, 2019 at 3:25 AM Steffen Klassert > <steffen.klassert@secunet.com> wrote: > > > > This adds a new NETIF_F_GRO_LIST feature flag. I will be used > > to configure listfyed GRO what will be implemented with some > > followup paches. > > This should probably simultaneously introduce SKB_GSO_FRAGLIST as well > as a BUILD_BUG_ON in net_gso_ok. Yes, good point. I'll also rename NETIF_F_GRO_LIST to NETIF_F_GRO_FRAGLIST and add NETIF_F_GSO_FRAGLIST what is currently missing. > > Please also in the commit describe the constraints of skbs that have > this type. If I'm not mistaken, an skb with either gso_size linear > data or one gso_sized frag, followed by a frag_list of the same. With > the exception of the last frag_list member, whose mss may be less than > gso_size. This will help when reasoning about all the types of skbs we > may see at segmentation, as we recently had to do [1] We don't use skb_segment(), so I think we don't have this constraint. > > Minor nit: I think it's listified, not listifyed. I think neither of both words really exist :) I'll rename it to fraglist GRO.
On Wed, Sep 18, 2019 at 08:04:18PM -0600, Subash Abhinov Kasiviswanathan wrote: > On 2019-09-18 10:10, Willem de Bruijn wrote: > > On Wed, Sep 18, 2019 at 3:25 AM Steffen Klassert > > <steffen.klassert@secunet.com> wrote: > > > > > > This adds a new NETIF_F_GRO_LIST feature flag. I will be used > > > to configure listfyed GRO what will be implemented with some > > > followup paches. > > > > This should probably simultaneously introduce SKB_GSO_FRAGLIST as well > > as a BUILD_BUG_ON in net_gso_ok. > > > > Please also in the commit describe the constraints of skbs that have > > this type. If I'm not mistaken, an skb with either gso_size linear > > data or one gso_sized frag, followed by a frag_list of the same. With > > the exception of the last frag_list member, whose mss may be less than > > gso_size. This will help when reasoning about all the types of skbs we > > may see at segmentation, as we recently had to do [1] > > > > Would it be preferrable to allow any size skbs for the listification. We currently require a single gso_size because we adjust uh->len on the head skb to the full size to do correct memory accounting on the local input path. That is going to be restored with the gso_size on segmentation. > Since the original skbs are being restored, single gso_size shoudln't > be a constraint here. It might be possible to allow any sized skbs with some extra work, though.
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h index 4b19c544c59a..1b6baa1b6fe9 100644 --- a/include/linux/netdev_features.h +++ b/include/linux/netdev_features.h @@ -80,6 +80,7 @@ enum { NETIF_F_GRO_HW_BIT, /* Hardware Generic receive offload */ NETIF_F_HW_TLS_RECORD_BIT, /* Offload TLS record */ + NETIF_F_GRO_LIST_BIT, /* Listifyed GRO */ /* * Add your fresh new feature above and remember to update @@ -150,6 +151,7 @@ enum { #define NETIF_F_GSO_UDP_L4 __NETIF_F(GSO_UDP_L4) #define NETIF_F_HW_TLS_TX __NETIF_F(HW_TLS_TX) #define NETIF_F_HW_TLS_RX __NETIF_F(HW_TLS_RX) +#define NETIF_F_GRO_LIST __NETIF_F(GRO_LIST) /* Finds the next feature with the highest number of the range of start till 0. */ diff --git a/net/core/ethtool.c b/net/core/ethtool.c index 6288e69e94fc..ee8d2b58c2d7 100644 --- a/net/core/ethtool.c +++ b/net/core/ethtool.c @@ -111,6 +111,7 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN] [NETIF_F_HW_TLS_RECORD_BIT] = "tls-hw-record", [NETIF_F_HW_TLS_TX_BIT] = "tls-hw-tx-offload", [NETIF_F_HW_TLS_RX_BIT] = "tls-hw-rx-offload", + [NETIF_F_GRO_LIST_BIT] = "rx-gro-list", }; static const char
This adds a new NETIF_F_GRO_LIST feature flag. I will be used to configure listfyed GRO what will be implemented with some followup paches. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> --- include/linux/netdev_features.h | 2 ++ net/core/ethtool.c | 1 + 2 files changed, 3 insertions(+)