All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Daniel Axtens <dja@axtens.net>, netdev@vger.kernel.org
Cc: Manish.Chopra@cavium.com, Jason Wang <jasowang@redhat.com>,
	Pravin Shelar <pshelar@ovn.org>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Subject: Re: [PATCH v3 1/2] net: create skb_gso_validate_mac_len()
Date: Mon, 29 Jan 2018 17:59:01 -0800	[thread overview]
Message-ID: <1517277541.3715.95.camel@gmail.com> (raw)
In-Reply-To: <1517276779.3715.92.camel@gmail.com>

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 <dja@axtens.net>
> > ---
> >  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.

  reply	other threads:[~2018-01-30  1:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30  1:14 [PATCH v3 0/2] bnx2x: disable GSO on too-large packets Daniel Axtens
2018-01-30  1:14 ` [PATCH v3 1/2] net: create skb_gso_validate_mac_len() Daniel Axtens
2018-01-30  1:46   ` Eric Dumazet
2018-01-30  1:59     ` Eric Dumazet [this message]
2018-01-30  2:42       ` Daniel Axtens
2018-01-30  8:17   ` Marcelo Ricardo Leitner
2018-01-30 13:08     ` Daniel Axtens
2018-01-30 16:59   ` kbuild test robot
2018-01-30 17:00   ` kbuild test robot
2018-01-30  1:14 ` [PATCH v3 2/2] bnx2x: disable GSO where gso_size is too big for hardware Daniel Axtens
2018-01-30  8:20 ` [PATCH v3 0/2] bnx2x: disable GSO on too-large packets Marcelo Ricardo Leitner

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=1517277541.3715.95.camel@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=Manish.Chopra@cavium.com \
    --cc=dja@axtens.net \
    --cc=jasowang@redhat.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@ovn.org \
    /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.