[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2fd24801-bf77-02e3-03f5-b5e8fac595b6@redhat.com>
Date: Thu, 10 Jun 2021 13:23:44 +0800
From: Jason Wang <jasowang@...hat.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Tanner Love <tannerlove.kernel@...il.com>,
Network Development <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Petar Penkov <ppenkov@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
"Michael S . Tsirkin" <mst@...hat.com>,
Tanner Love <tannerlove@...gle.com>
Subject: Re: [PATCH net-next v4 2/3] virtio_net: add optional flow dissection
in virtio_net_hdr_to_skb
在 2021/6/10 下午12:19, Alexei Starovoitov 写道:
> On Wed, Jun 9, 2021 at 9:13 PM Jason Wang <jasowang@...hat.com> wrote:
>> So I wonder why not simply use helpers to access the vnet header like
>> how tcp-bpf access the tcp header?
> Short answer - speed.
> tcp-bpf accesses all uapi and non-uapi structs directly.
>
Ok, this makes sense. But instead of coupling device specific stuffs
like vnet header and neediness into general flow_keys as a context.
It would be better to introduce a vnet header context which contains
1) vnet header
2) flow keys
3) other contexts like endian and virtio-net features
So we preserve the performance and decouple the virtio-net stuffs from
general structures like flow_keys or __sk_buff.
Thanks
Powered by blists - more mailing lists