From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Luigi Rizzo <lrizzo@google.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, Jesper Dangaard Brouer <hawk@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
sameehj@amazon.com
Subject: Re: [PATCH] net-xdp: netdev attribute to control xdpgeneric skb linearization
Date: Fri, 24 Jan 2020 22:27:58 +0100 [thread overview]
Message-ID: <87a76cfstd.fsf@toke.dk> (raw)
In-Reply-To: <CAMOZA0KZOyEjJj3N7WQNRYi+n91UKkWihQRjxdrbCs9JdM5cbg@mail.gmail.com>
Luigi Rizzo <lrizzo@google.com> writes:
> On Fri, Jan 24, 2020 at 7:31 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Luigi Rizzo <lrizzo@google.com> writes:
>>
> ...
>> > My motivation for this change is that enforcing those guarantees has
>> > significant cost (even for native xdp in the cases I mentioned - mtu >
>> > 1 page, hw LRO, header split), and this is an interim solution to make
>> > generic skb usable without too much penalty.
>>
>> Sure, that part I understand; I just don't like that this "interim"
>> solution makes generic and native XDP diverge further in their
>> semantics...
>
> As a matter of fact I think it would make full sense to use the same approach
> to control whether native xdp should pay the price converting to linear buffers
> when the hw cannot guarantee that.
>
> To me this seems to be a case of "perfect is enemy of good":..
Hmm, I can kinda see your point (now that I've actually grok'ed how the
length works with skbs and generic XDP :)). I would still worry that
only having the header there would lead some XDP programs to just
silently fail. But on the other hand, this is opt-in... so IDK - maybe
this is fine to merge as-is, and leave improvements for later?
-Toke
next prev parent reply other threads:[~2020-01-24 21:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 20:32 [PATCH] net-xdp: netdev attribute to control xdpgeneric skb linearization Luigi Rizzo
2020-01-23 9:53 ` Toke Høiland-Jørgensen
2020-01-23 15:48 ` Daniel Borkmann
2020-01-23 16:14 ` Toke Høiland-Jørgensen
2020-01-23 17:30 ` Luigi Rizzo
2020-01-23 18:01 ` Toke Høiland-Jørgensen
2020-01-23 18:06 ` Luigi Rizzo
2020-01-23 21:36 ` Daniel Borkmann
2020-01-24 9:57 ` Toke Høiland-Jørgensen
2020-01-24 14:31 ` Luigi Rizzo
2020-01-24 15:30 ` Toke Høiland-Jørgensen
2020-01-24 17:15 ` Luigi Rizzo
2020-01-24 21:27 ` Toke Høiland-Jørgensen [this message]
2020-02-05 15:36 ` Luigi Rizzo
[not found] ` <CA+hQ2+hnqifXzyHjjc5TXJmJz_EVCbuF6vGchKjaWccfK2ZA4g@mail.gmail.com>
2020-02-05 15:55 ` Toke Høiland-Jørgensen
2020-01-23 17:25 ` Luigi Rizzo
2020-01-23 18:00 ` Toke Høiland-Jørgensen
2020-01-23 18:11 ` Luigi Rizzo
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=87a76cfstd.fsf@toke.dk \
--to=toke@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=hawk@kernel.org \
--cc=lrizzo@google.com \
--cc=netdev@vger.kernel.org \
--cc=sameehj@amazon.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.