[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89i+AZ9PnRssWpiE5zj41V1=85Jcy80Rtbp7mLjp73Y71Pw@mail.gmail.com>
Date: Mon, 27 Jul 2020 08:24:55 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Jonathan Lemon <jonathan.lemon@...il.com>
Cc: netdev <netdev@...r.kernel.org>, kernel-team <kernel-team@...com>,
Christoph Hellwig <hch@....de>,
Robin Murphy <robin.murphy@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Willem de Bruijn <willemb@...gle.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Maxim Mikityanskiy <maximmi@...lanox.com>,
bjorn.topel@...el.com, magnus.karlsson@...el.com,
borisp@...lanox.com, david@...hat.com
Subject: Re: [RFC PATCH v2 08/21] skbuff: add a zc_netgpu bitflag
On Mon, Jul 27, 2020 at 12:20 AM Jonathan Lemon
<jonathan.lemon@...il.com> wrote:
>
> This could likely be moved elsewhere. The presence of the flag on
> the skb indicates that one of the fragments may contain zerocopy
> RX data, where the data is not accessible to the cpu.
Why do we need yet another flag in skb exactly ?
Please define what means "data not accessible to the cpu" ?
This kind of change is a red flag for me.
Powered by blists - more mailing lists