From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH v3 1/2] net: create skb_gso_validate_mac_len() Date: Mon, 29 Jan 2018 17:59:01 -0800 Message-ID: <1517277541.3715.95.camel@gmail.com> References: <20180130011447.24916-1-dja@axtens.net> <20180130011447.24916-2-dja@axtens.net> <1517276779.3715.92.camel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Manish.Chopra@cavium.com, Jason Wang , Pravin Shelar , Marcelo Ricardo Leitner To: Daniel Axtens , netdev@vger.kernel.org Return-path: Received: from mail-pf0-f195.google.com ([209.85.192.195]:37939 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752501AbeA3B7D (ORCPT ); Mon, 29 Jan 2018 20:59:03 -0500 Received: by mail-pf0-f195.google.com with SMTP id k19so7215276pfj.5 for ; Mon, 29 Jan 2018 17:59:03 -0800 (PST) In-Reply-To: <1517276779.3715.92.camel@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 2018-01-29 at 17:46 -0800, Eric Dumazet wrote: > On Tue, 2018-01-30 at 12:14 +1100, Daniel Axtens wrote: > > If you take a GSO skb, and split it into packets, will the MAC > > length (L2 + L3 + L4 headers + payload) of those packets be small > > enough to fit within a given length? > > > > Move skb_gso_mac_seglen() to skbuff.h with other related functions > > like skb_gso_network_seglen() so we can use it, and then create > > skb_gso_validate_mac_len to do the full calculation. > > > > Signed-off-by: Daniel Axtens > > --- > > include/linux/skbuff.h | 16 +++++++++++++ > > net/core/skbuff.c | 65 +++++++++++++++++++++++++++++++++++++++----------- > > net/sched/sch_tbf.c | 10 -------- > > 3 files changed, 67 insertions(+), 24 deletions(-) > > > > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > > index b8e0da6c27d6..242d6773c7c2 100644 > > --- a/include/linux/skbuff.h > > +++ b/include/linux/skbuff.h > > @@ -3287,6 +3287,7 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen); > > void skb_scrub_packet(struct sk_buff *skb, bool xnet); > > unsigned int skb_gso_transport_seglen(const struct sk_buff *skb); > > bool skb_gso_validate_mtu(const struct sk_buff *skb, unsigned int mtu); > > +bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len); > > struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features); > > struct sk_buff *skb_vlan_untag(struct sk_buff *skb); > > int skb_ensure_writable(struct sk_buff *skb, int write_len); > > @@ -4120,6 +4121,21 @@ static inline unsigned int skb_gso_network_seglen(const struct sk_buff *skb) > > return hdr_len + skb_gso_transport_seglen(skb); > > } > > > > +/** > > + * skb_gso_mac_seglen - Return length of individual segments of a gso packet > > + * > > + * @skb: GSO skb > > + * > > + * skb_gso_mac_seglen is used to determine the real size of the > > + * individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4 > > + * headers (TCP/UDP). > > + */ > > +static inline unsigned int skb_gso_mac_seglen(const struct sk_buff *skb) > > +{ > > + unsigned int hdr_len = skb_transport_header(skb) - skb_mac_header(skb); > > + return hdr_len + skb_gso_transport_seglen(skb); > > +} > > skb_gso_transport_seglen(skb) is quite expensive (out of line) > > It is unfortunate bnx2x seems to support 9600 MTU ( > ETH_MAX_JUMBO_PACKET_SIZE ), because 100 bytes of headers can be too > small in some cases. > > Presumably we could avoid calling the function for standard MTU <= 9000 Also are we sure about these bnx2x crashes being limited to TSO ? Maybe it will crash the same after GSO has segmented the packet and we provide a big (like 10,000 bytes) packet ? I do not believe upper stack will prevent this.