v6:
https://lore.kernel.org/netdev/20250222191517.743530-1-almasrym...@google.com/
===
v6 has no major changes. Addressed a few issues from Paolo and David,
and collected Acks from Stan. Thank you everyone for the review!
Changes:
- retain behavior to process MSG_FASTOPEN even if the provided cm
Currently net_iovs support only pp ref counts, and do not support a
page ref equivalent.
This is fine for the RX path as net_iovs are used exclusively with the
pp and only pp refcounting is needed there. The TX path however does not
use pp ref counts, thus, support for get_page/put_page equivalent
From: Stanislav Fomichev
Add bind-tx netlink call to attach dmabuf for TX; queue is not
required, only ifindex and dmabuf fd for attachment.
Signed-off-by: Stanislav Fomichev
Signed-off-by: Mina Almasry
---
v3:
- Fix ynl-regen.sh error (Simon).
---
Documentation/netlink/specs/netdev.yaml |
Augment dmabuf binding to be able to handle TX. Additional to all the RX
binding, we also create tx_vec needed for the TX path.
Provide API for sendmsg to be able to send dmabufs bound to this device:
- Provide a new dmabuf_tx_cmsg which includes the dmabuf to send from.
- MSG_ZEROCOPY with SCM_D
Add documentation outlining the usage and details of the devmem TCP TX
API.
Signed-off-by: Mina Almasry
Acked-by: Stanislav Fomichev
---
v5:
- Address comments from Stan and Bagas
v4:
- Mention SO_BINDTODEVICE is recommended (me/Pavel).
v2:
- Update documentation for iov_base is the dmabuf o
Use netmem_dma_*() helpers in gve_tx_dqo.c DQO-RDA paths to
enable netmem TX support in that mode.
Declare support for netmem TX in GVE DQO-RDA mode.
Signed-off-by: Mina Almasry
---
v4:
- New patch
---
drivers/net/ethernet/google/gve/gve_main.c | 4
drivers/net/ethernet/google/gve/gve_
Add support for devmem TX in ncdevmem.
This is a combination of the ncdevmem from the devmem TCP series RFCv1
which included the TX path, and work by Stan to include the netlink API
and refactored on top of his generic memory_provider support.
Signed-off-by: Mina Almasry
Signed-off-by: Stanislav
We should not enable netmem TX for drivers that don't declare support.
Check for driver netmem TX support during devmem TX binding and fail if
the driver does not have the functionality.
Check for driver support in validate_xmit_skb as well.
Signed-off-by: Mina Almasry
Acked-by: Stanislav Fomic
Drivers need to make sure not to pass netmem dma-addrs to the
dma-mapping API in order to support netmem TX.
Add helpers and netmem_dma_*() helpers that enables special handling of
netmem dma-addrs that drivers can use.
Document in netmem.rst what drivers need to do to support netmem TX.
Signed-
On Tue, Feb 25, 2025 at 07:48:21PM +0100, Krzysztof Kozlowski wrote:
> Document two rules already widely used and enforced by DT maintainers
> and SoC platform maintainers:
>
> 1. DTS patches should be placed at the end of driver patchset to
>indicate no dependencies of driver code on DTS.
>
On 26.02.25 16:14, Patrick Roy wrote:
On Wed, 2025-02-26 at 09:08 +, David Hildenbrand wrote:
On 26.02.25 09:48, Patrick Roy wrote:
On Tue, 2025-02-25 at 16:54 +, David Hildenbrand wrote:> On 21.02.25 17:07,
Patrick Roy wrote:
Add KVM_GMEM_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_M
On Wed, 2025-02-26 at 09:08 +, David Hildenbrand wrote:
> On 26.02.25 09:48, Patrick Roy wrote:
>>
>>
>> On Tue, 2025-02-25 at 16:54 +, David Hildenbrand wrote:> On 21.02.25
>> 17:07, Patrick Roy wrote:
Add KVM_GMEM_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD() ioctl. When
s
On 2/25/25 11:54 AM, Mina Almasry wrote:
>
> Will do, although I think maybe I'll add that comment above the
> refcount_t definition in net_devmem_dmabuf_binding, if that's OK with
> you. That was meant to explain how the refcounting on the binding
> works.
>
That is fine, I just think the lifec
On Tue, Feb 25, 2025 at 07:48:22PM +0100, Krzysztof Kozlowski wrote:
> Devicetree bindings patches go usually via driver subsystem tree, so
> obviously testing only SoC branches would result in new dtbs_check
> warnings. Mention that linux-next branch is decisice for zero-warnings
> rule.
>
> Sig
On 26/02/2025 16:29, Rob Herring wrote:
> On Tue, Feb 25, 2025 at 07:48:22PM +0100, Krzysztof Kozlowski wrote:
>> Devicetree bindings patches go usually via driver subsystem tree, so
>> obviously testing only SoC branches would result in new dtbs_check
>> warnings. Mention that linux-next branch i
Hi Alex,
On Tue, Feb 25, 2025 at 10:07 PM Alexandre Ghiti wrote:
>
> On Tue, Feb 25, 2025 at 2:27 PM yunhui cui wrote:
> >
> > Hi Alex,
> >
> > On Tue, Feb 25, 2025 at 9:21 PM Alexandre Ghiti
> > wrote:
> > >
> > > Hi Yunhui,
> > >
> > > On Wed, Jan 15, 2025 at 3:40 AM Yunhui Cui
> > > wrote
On Tue, 2025-02-25 at 16:54 +, David Hildenbrand wrote:> On 21.02.25 17:07,
Patrick Roy wrote:
>> Add KVM_GMEM_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD() ioctl. When
>> set, guest_memfd folios will be removed from the direct map after
>> preparation, with direct map entries only restor
On Tue, 2025-02-25 at 16:55 +, David Hildenbrand wrote:
> On 21.02.25 17:07, Patrick Roy wrote:
>> Add a capability to let userspace discover whether guest_memfd supports
>> removing its folios from the direct map. Support depends on guest_memfd
>> itself being supported, but also on whether
On Tue, 2025-02-25 at 16:52 +, David Hildenbrand wrote:> On 21.02.25 17:07,
Patrick Roy wrote:
>> Make secretmem set AS_NO_DIRECT_MAP on its struct address_space, to drop
>> all the vma_is_secretmem()/secretmem_mapping() checks that are based on
>> checking explicitly for the secretmem ops
On 26.02.25 09:48, Patrick Roy wrote:
On Tue, 2025-02-25 at 16:54 +, David Hildenbrand wrote:> On 21.02.25 17:07,
Patrick Roy wrote:
Add KVM_GMEM_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD() ioctl. When
set, guest_memfd folios will be removed from the direct map after
preparation, with
20 matches
Mail list logo
