netdev - Re: [RFC PATCH v2 02/11] netdev: implement netlink api to bind dma-buf to netdevice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-KgNDzv3-MhOMOTe2bTw4T73t-M7D65MpeG6vDBqHzrtA@mail.gmail.com>
Date: Sat, 19 Aug 2023 10:18:57 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: David Ahern <dsahern@...nel.org>
Cc: Jakub Kicinski <kuba@...nel.org>, Mina Almasry <almasrymina@...gle.com>, 
	Praveen Kaligineedi <pkaligineedi@...gle.com>, netdev@...r.kernel.org, 
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Jesper Dangaard Brouer <hawk@...nel.org>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, 
	Magnus Karlsson <magnus.karlsson@...el.com>, sdf@...gle.com, 
	Willem de Bruijn <willemb@...gle.com>, Kaiyuan Zhang <kaiyuanz@...gle.com>
Subject: Re: [RFC PATCH v2 02/11] netdev: implement netlink api to bind
 dma-buf to netdevice

On Fri, Aug 18, 2023 at 11:30 PM David Ahern <dsahern@...nel.org> wrote:
>
> On 8/18/23 8:06 PM, Jakub Kicinski wrote:
> > On Fri, 18 Aug 2023 19:34:32 -0600 David Ahern wrote:
> >> On 8/18/23 3:52 PM, Mina Almasry wrote:
> >>> The sticking points are:
> >>> 1. From David: this proposal doesn't give an application the ability
> >>> to flush an rx queue, which means that we have to rely on a driver
> >>> reset that affects all queues to refill the rx queue buffers.
> >>
> >> Generically, the design needs to be able to flush (or invalidate) all
> >> references to the dma-buf once the process no longer "owns" it.
> >
> > Are we talking about the ability for the app to flush the queue
> > when it wants to (do no idea what)? Or auto-flush when app crashes?
>
> If a buffer reference can be invalidated such that a posted buffer is
> ignored by H/W, then no flush is needed per se. Either way the key point
> is that posted buffers can no longer be filled by H/W once a process no
> longer owns the dma-buf reference. I believe the actual mechanism here
> will vary by H/W.

Right. Many devices only allow bringing all queues down at the same time.

Once a descriptor is posted and the ring head is written, there is no
way to retract that. Since waiting for the device to catch up is not
acceptable, the only option is to bring down the queue, right? Which
will imply bringing down the entire device on many devices. Not ideal,
but acceptable short term, imho.

That may be an incentive for vendors to support per-queue
start/stop/alloc/free. Maybe the ones that support RDMA already do?