netdev - RE: [RFC PATCH v2 00/11] Device Memory TCP

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: <58a93e4e8b8b4ca79c2678a3ae8281cd@AcuMS.aculab.com>
Date: Tue, 15 Aug 2023 13:38:23 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Mina Almasry' <almasrymina@...gle.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-media@...r.kernel.org"
	<linux-media@...r.kernel.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>
CC: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Jesper Dangaard Brouer <hawk@...nel.org>, "Ilias
 Apalodimas" <ilias.apalodimas@...aro.org>, Arnd Bergmann <arnd@...db.de>,
	David Ahern <dsahern@...nel.org>, Willem de Bruijn
	<willemdebruijn.kernel@...il.com>, Sumit Semwal <sumit.semwal@...aro.org>,
	Christian König <christian.koenig@....com>, "Jason
 Gunthorpe" <jgg@...pe.ca>, Hari Ramakrishnan <rharix@...gle.com>, Dan
 Williams <dan.j.williams@...el.com>, Andy Lutomirski <luto@...nel.org>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>, "sdf@...gle.com"
	<sdf@...gle.com>
Subject: RE: [RFC PATCH v2 00/11] Device Memory TCP

From: Mina Almasry
> Sent: 10 August 2023 02:58
...
> * TL;DR:
> 
> Device memory TCP (devmem TCP) is a proposal for transferring data to and/or
> from device memory efficiently, without bouncing the data to a host memory
> buffer.

Doesn't that really require peer-to-peer PCIe transfers?
IIRC these aren't supported by many root hubs and have
fundamental flow control and/or TLP credit problems.

I'd guess they are also pretty incompatible with IOMMU?

I can see how you might manage to transmit frames from
some external memory (eg after encryption) but surely
processing receive data that way needs the packets
be filtered by both IP addresses and port numbers before
being redirected to the (presumably limited) external
memory.

OTOH isn't the kernel going to need to run code before
the packet is actually sent and just after it is received?
So all you might gain is a bit of latency?
And a bit less utilisation of host memory??
But if your system is really limited by cpu-memory bandwidth
you need more cache :-)

So how much benefit is there over efficient use of host
memory bounce buffers??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)