netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: Eric Dumazet <eric.dumazet@gmail.com>, 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: Tue, 30 Jan 2018 13:42:38 +1100	[thread overview]
Message-ID: <87d11srrs1.fsf@linkitivity.dja.id.au> (raw)
In-Reply-To: <1517277541.3715.95.camel@gmail.com>

Hi Eric,

>> 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

Yes, it is an expensive call. I will send another version where we only
call the expensive path in the jumbo frame case. I'll wait until
tomorrow in case there is any more feedback in the next 24 hours or so.

> 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.

We did test with TSO off and that was sufficient to prevent the crash.

You are right that the upper stack sends down the 10k packet, so I don't
know why it prevents the crash. But we did definitely test it! I don't
have access to the firmware details but I imagine it's an issue with the
offloaded segmentation.

Thanks for your patience with the many versions of this patch set.

Regards,
Daniel

  reply	other threads:[~2018-01-30  2:42 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
2018-01-30  2:42       ` Daniel Axtens [this message]
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=87d11srrs1.fsf@linkitivity.dja.id.au \
    --to=dja@axtens.net \
    --cc=Manish.Chopra@cavium.com \
    --cc=eric.dumazet@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).