Thread (26 messages) 26 messages, 5 authors, 2025-02-10

Re: [PATCH RFC net-next v1 5/5] net: devmem: Implement TX path

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2025-01-28 14:50:02
Also in: kvm, linux-doc, linux-kselftest, lkml, netdev

quoted
quoted
+struct net_devmem_dmabuf_binding *
+net_devmem_get_sockc_binding(struct sock *sk, struct sockcm_cookie *sockc)
+{
+     struct net_devmem_dmabuf_binding *binding;
+     int err = 0;
+
+     binding = net_devmem_lookup_dmabuf(sockc->dmabuf_id);
This lookup is from global xarray net_devmem_dmabuf_bindings.

Is there a check that the socket is sending out through the device
to which this dmabuf was bound with netlink? Should there be?
(e.g., SO_BINDTODEVICE).
Yes, I think it may be an issue if the user triggers a send from a
different netdevice, because indeed when we bind a dmabuf we bind it
to a specific netdevice.

One option is as you say to require TX sockets to be bound and to
check that we're bound to the correct netdev. I also wonder if I can
make this work without SO_BINDTODEVICE, by querying the netdev the
sock is currently trying to send out on and doing a check in the
tcp_sendmsg. I'm not sure if this is possible but I'll give it a look.
I was a bit quick on mentioning SO_BINDTODEVICE. Agreed that it is
vastly preferable to not require that, but infer the device from
the connected TCP sock.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help