[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHS8izNrmM1=vEwYWHizHFG2-Kdq2oKhQo9ZSSy6Z2_qoxVqSQ@mail.gmail.com>
Date: Wed, 10 Jul 2024 16:07:32 -0700
From: Mina Almasry <almasrymina@...gle.com>
To: Tony Nguyen <anthony.l.nguyen@...el.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
edumazet@...gle.com, netdev@...r.kernel.org,
Alexander Lobakin <aleksander.lobakin@...el.com>, nex.sw.ncis.osdt.itp.upstreaming@...el.com,
lihong.yang@...el.com, willemb@...gle.com,
Przemek Kitszel <przemyslaw.kitszel@...el.com>, Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH net-next 10/14] idpf: reuse libeth's definitions of parsed
ptype structures
On Wed, Jul 10, 2024 at 1:30 PM Tony Nguyen <anthony.l.nguyen@...el.com> wrote:
>
> From: Alexander Lobakin <aleksander.lobakin@...el.com>
>
> idpf's in-kernel parsed ptype structure is almost identical to the one
> used in the previous Intel drivers, which means it can be converted to
> use libeth's definitions and even helpers. The only difference is that
> it doesn't use a constant table (libie), rather than one obtained from
> the device.
> Remove the driver counterpart and use libeth's helpers for hashes and
> checksums. This slightly optimizes skb fields processing due to faster
> checks. Also don't define big static array of ptypes in &idpf_vport --
> allocate them dynamically. The pointer to it is anyway cached in
> &idpf_rx_queue.
>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@...el.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@...el.com>
Reviewed-by: Mina Almasry <almasrymina@...gle.com>
Powered by blists - more mailing lists