From: David Miller <davem@davemloft.net>
To: maheshb@google.com
Cc: michael.chan@broadcom.com, dja@axtens.net,
netdev@vger.kernel.org, edumazet@google.com, willemb@google.com
Subject: Re: Stack sends oversize UDP packet to the driver
Date: Tue, 22 Jan 2019 12:09:37 -0800 (PST) [thread overview]
Message-ID: <20190122.120937.355805969121598441.davem@davemloft.net> (raw)
In-Reply-To: <CAF2d9jhL_uzV_Er1gJ1eiUUUbJsPH4OHm5Lsbi0HnvnBdNekFQ@mail.gmail.com>
From: Mahesh Bandewar (महेश बंडेवार) <maheshb@google.com>
Date: Tue, 22 Jan 2019 10:28:58 -0800
> On Mon, Jan 21, 2019 at 4:59 PM Michael Chan <michael.chan@broadcom.com> wrote:
>>
>> On Mon, Jan 21, 2019 at 4:36 PM Daniel Axtens <dja@axtens.net> wrote:
>>
>> > I hit a similar sounding issue on a bnx2x - see commit
>> > 8914a595110a6eca69a5e275b323f5d09e18f4f9
>> >
>> > In that case, a GSO packet with gso_size too large for the firmware was
>> > coming to the bnx2x driver from an ibmveth device via Open vSwitch. I
>> > also toyed with a fix in the stack and ended up fixing just the driver.
>>
>> Hi Daniel, yes I remember the issue that you reported at that time.
>> The current issue is similar but for non-TSO UDP packets.
I just want to step in and say that I really don't want drivers to have to
deal with this problem, if possible. Drivers are hard enough to write
already.
However, some aspects of this problem, like the MTU changes, route flaps,
packet mirroring, etc. are all in one way or another asynchonous to the
data fast path and therefore we may end up having to do something like
this afterall right at the last step before ->ndo_start_xmit() or similar.
Just my $0.02
next prev parent reply other threads:[~2019-01-22 20:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-20 22:26 Stack sends oversize UDP packet to the driver Michael Chan
2019-01-22 0:36 ` Daniel Axtens
2019-01-22 0:59 ` Michael Chan
2019-01-22 18:28 ` Mahesh Bandewar (महेश बंडेवार)
2019-01-22 20:09 ` David Miller [this message]
2019-01-30 9:07 ` Michael Chan
2019-01-31 1:00 ` Mahesh Bandewar (महेश बंडेवार)
2019-02-05 19:35 ` Michael Chan
2019-02-07 4:51 ` Mahesh Bandewar (महेश बंडेवार)
2019-02-08 20:26 ` Mahesh Bandewar (महेश बंडेवार)
2019-02-12 8:55 ` Michael Chan
[not found] ` <CAF2d9jgskHTb-nmbVo9A2CQhh9T3OnH_vbfGcMBii13oq1teCw@mail.gmail.com>
2019-01-22 0:45 ` Michael Chan
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=20190122.120937.355805969121598441.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=dja@axtens.net \
--cc=edumazet@google.com \
--cc=maheshb@google.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
/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.