[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d11srrs1.fsf@linkitivity.dja.id.au>
Date: Tue, 30 Jan 2018 13:42:38 +1100
From: Daniel Axtens <dja@...ens.net>
To: Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Cc: Manish.Chopra@...ium.com, Jason Wang <jasowang@...hat.com>,
"Pravin Shelar" <pshelar@....org>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Subject: Re: [PATCH v3 1/2] net: create skb_gso_validate_mac_len()
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
Powered by blists - more mailing lists