On Fri, 09 May 2025 11:53:36 -0400 Jeff Layton wrote:
> This one just fixes a typo in the ref_tracker_dir_init() kerneldoc
> header. I'm only resending so the CI will pick it up.
We got a bunch of:
[0.457561][T0] ref_tracker: ref_tracker: unable to create debugfs file
for net_refcnt@
On Fri, 09 May 2025 09:36:57 -0400 Jeff Layton wrote:
> On Wed, 2025-05-07 at 20:01 -0700, Jakub Kicinski wrote:
> > On Wed, 07 May 2025 09:06:35 -0400 Jeff Layton wrote:
> > > + * @quarantime_count: max number of entries to be tracked
> >
> > quarantime
> &
On Wed, 07 May 2025 09:06:35 -0400 Jeff Layton wrote:
> + * @quarantime_count: max number of entries to be tracked
quarantime
^
:(
--
pw-bot: cr
On Tue, 29 Apr 2025 19:18:01 -0700 Jeff Layton wrote:
> On Tue, 2025-04-29 at 16:27 -0700, Jakub Kicinski wrote:
> > On Mon, 28 Apr 2025 11:26:27 -0700 Jeff Layton wrote:
> > > Allow pr_ostream to also output directly to a seq_file without an
> > > intermediate buffe
On Mon, 28 Apr 2025 11:26:29 -0700 Jeff Layton wrote:
> +/**
> + * ref_tracker_dir_debugfs - create debugfs file for ref_tracker_dir
> + * @dir: ref_tracker_dir to be associated with debugfs file
> + * @fmt: format string for filename
> + * @...: arguments for the format string
> + *
> + * Call thi
On Mon, 28 Apr 2025 11:26:27 -0700 Jeff Layton wrote:
> Allow pr_ostream to also output directly to a seq_file without an
> intermediate buffer.
>
> Reviewed-by: Andrew Lunn
> Signed-off-by: Jeff Layton
lib/ref_tracker.c:316:12: warning: unused function 'ref_tracker_dir_seq_print'
[-Wunused-fu
On Mon, 28 Apr 2025 11:26:23 -0700 Jeff Layton wrote:
> This one is quite a bit of a change from the last set. I've gone back to
> auto-registering the debugfs files for every ref_tracker_dir. With this,
> the callers should pass in a static string as a classname instead of an
> individual name str
On Tue, 10 Dec 2024 18:50:40 -0800 Andrew Morton wrote:
> > > Very unlikely, and any such conflict will be trivial.
> >
> > Agreed, mainly I don't understand why we'd make an exception
> > and take the patchset via a special tree.
>
> It saves work for everyone?
>
> The patches are super-sim
On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > I'll just grab everything and see if anyone complains ;)
> >
> > I may, if this leads to a conflict :(
>
> Very unlikely, and any such conflict will be trivial.
Agreed, mainly I don't understand why we'd make an exception
and take
On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > I have the same question as before: How do you expect these to land?
> > Do you now have a maintainer who will take all of them?
> > Or do you want individual maintainers to take the ones applicable to them?
>
> I'll just grab everythin
On Thu, 10 Oct 2024 12:05:38 -0700 Mina Almasry wrote:
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 083d438d8b6f..cb3d8b19de14 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1071,11 +1071,11 @@ sock_devmem_dontneed(struct sock *sk,
> sockptr_t optval, unsigned int optlen)
On Mon, 9 Sep 2024 05:43:05 + Mina Almasry wrote:
> 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.
Mina, if you'd like to see this in v6.12 -- please fix the nits and
repost AS
On Mon, 9 Sep 2024 05:43:15 + Mina Almasry wrote:
> --- a/include/uapi/linux/uio.h
> +++ b/include/uapi/linux/uio.h
> @@ -33,6 +33,10 @@ struct dmabuf_cmsg {
>*/
> };
>
> +struct dmabuf_token {
> + __u32 token_start;
> + __u32 token_count;
> +};
> /*
a Almasry
> Reviewed-by: Eric Dumazet
I'm sure we'll find more cases which need a check but I can't think
of any now, so:
Reviewed-by: Jakub Kicinski
t; @@ -11,6 +11,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -24,8 +25,10 @@
>
> #include
>
> +#include "mp_dmabuf_devmem.h"
> #include "netmem_priv.h"
> #include "page_pool_priv.h"
> +#include "mp_dmabuf_devmem.h"
nit: duplicate include
With that:
Reviewed-by: Jakub Kicinski
--
pw-bot: cr
On Sat, 31 Aug 2024 00:43:11 + Mina Almasry wrote:
> +The socket must be flow steered to the dmabuf bound RX queue::
> +
> + ethtool -N eth1 flow-type tcp4 ... queue 15,
nit: tailing comma here
> +Devmem payloads are inaccessible to the kernel processing the packets. This
> +results in a
On Sat, 31 Aug 2024 00:43:08 + Mina Almasry wrote:
> static inline bool tcp_skb_can_collapse_to(const struct sk_buff *skb)
> {
> - return likely(!TCP_SKB_CB(skb)->eor);
> + return likely(!TCP_SKB_CB(skb)->eor && skb_frags_readable(skb));
Do you remember why this is here? Both for Rx
On Sat, 31 Aug 2024 00:43:07 + Mina Almasry wrote:
> Make skb_frag_page() fail in the case where the frag is not backed
> by a page, and fix its relevant callers to handle this case.
>
> Signed-off-by: Mina Almasry
> Reviewed-by: Eric Dumazet
Reviewed-by: Jakub Kicinski
On Sat, 31 Aug 2024 00:43:06 + Mina Almasry wrote:
> diff --git a/include/net/mp_dmabuf_devmem.h b/include/net/mp_dmabuf_devmem.h
> new file mode 100644
> index ..6d1cf2a77f6b
> --- /dev/null
> +++ b/include/net/mp_dmabuf_devmem.h
this header can live under net/core/ like netmem_pr
es an indicator in struct netdev_rx_queue
> that the given queue is bound, and the binding is actuated by resetting
> the rx queue using the queue API.
>
> The netdev_dmabuf_binding struct is refcounted, and releases its
> resources only when all the refs are released.
Reviewed-by: Jakub Kicinski
On Thu, 29 Aug 2024 22:41:17 -0700 Mina Almasry wrote:
> Thank you, I think the right fix here is to reacquire rtnl_lock before
> the `goto err_unbind;`, since err_unbind expects rtnl to be locked at
> this point.
FWIW it's best to keep the error path a mirror image of the success
path, so I'd add
On Thu, 29 Aug 2024 06:01:19 + Mina Almasry wrote:
> + if (WARN_ON_ONCE(atomic_long_read(netmem_get_pp_ref_count_ref(netmem))
> !=
> + 1))
nit: temporary variable for this refcount, please
On Thu, 29 Aug 2024 06:01:26 + Mina Almasry wrote:
> + binding = (struct net_devmem_dmabuf_binding *)
> + rxq->mp_params.mp_priv;
> + if (binding) {
> + if (nla_put_u32(rsp, NETDEV_A_QUEUE_DMABUF,
> +
On Thu, 29 Aug 2024 12:38:13 -0700 Mina Almasry wrote:
> BTW I submitted 2 iterations already this week, Sunday and Wednesday.
> This is easily fixable and I can resend before the end of the week,
> but if I'm stressing NIPA too much with reposts of this large series I
> can wait until next week. S
On Thu, 29 Aug 2024 06:01:16 + Mina Almasry wrote:
> @@ -9376,6 +9376,9 @@ int dev_xdp_propagate(struct net_device *dev, struct
> netdev_bpf *bpf)
> if (!dev->netdev_ops->ndo_bpf)
> return -EOPNOTSUPP;
>
> + if (dev_get_min_mp_channel_count(dev))
there's an extack in
On Thu, 29 Aug 2024 06:01:16 + Mina Almasry wrote:
> + if (NL_REQ_ATTR_CHECK(info->extack, attr, tb,
> NETDEV_A_QUEUE_ID) ||
> + NL_REQ_ATTR_CHECK(info->extack, attr, tb,
> NETDEV_A_QUEUE_TYPE) ||
> + nla_get_u32(tb[NETDEV_A_QUEUE_TYPE]) !=
> NETDE
On Thu, 29 Aug 2024 06:01:16 + Mina Almasry wrote:
> + if (dev_xdp_prog_count(netdev)) {
> + NL_SET_ERR_MSG(info->extack, "netdevice has xdp program
> attached");
> + return -EEXIST;
> + }
goto err_unlock
On Thu, 29 Aug 2024 06:01:16 + Mina Almasry wrote:
> + err = genlmsg_reply(rsp, info);
> + if (err)
> + goto err_unbind;
> +
> return 0;
> +
> +err_unbind:
rtnl_lock()
> + net_devmem_unbind_dmabuf(binding);
> +err_unlock:
> + rtnl_unlock();
On Wed, 28 Aug 2024 00:20:23 -0700 Mina Almasry wrote:
> > On Sun, 25 Aug 2024 04:15:02 + Mina Almasry wrote:
> > > +void net_devmem_free_dmabuf(struct net_iov *niov)
> > > +{
> > > + struct net_devmem_dmabuf_binding *binding = net_iov_binding(niov);
> > > + unsigned long dma_addr = n
if we're allocating
* system memory. Memory providers (which give us net_iovs)
* choose for us.
*/
Some of the code moves could be a separate patch, but either way:
Acked-by: Jakub Kicinski
l_has_addr(binding->chunk_pool, dma_addr, PAGE_SIZE))
> + gen_pool_free(binding->chunk_pool, dma_addr, PAGE_SIZE);
Is the check necessary for correctness? Should it perhaps be a WARN
under DEBUG_NET instead? The rest LGTM:
Reviewed-by: Jakub Kicinski
On Sun, 25 Aug 2024 04:15:01 + Mina Almasry wrote:
> +u32 dev_get_min_mp_channel_count(const struct net_device *dev)
> +{
> + u32 i, max = 0;
> +
> + ASSERT_RTNL();
> +
> + for (i = 0; i < dev->real_num_rx_queues; i++)
> + if (dev->_rx[i].mp_params.mp_priv)
> +
On Wed, 21 Aug 2024 11:36:31 -0400 Mina Almasry wrote:
> Additionally I'm wondering if we should disable adding mp-bound
> devices as slaves completely, regardless of xdp. My concern is that if
> the lower device is using unreadable memory, then the upper device may
> see unreadable memory in its c
On Tue, 20 Aug 2024 13:11:20 -0400 Mina Almasry wrote:
> > Protecting the stack from unreadable memory is *the* challenge
> > in this series. The rest is a fairly straightforward.
>
> Understandable. I pulled the trigger on v21 with the build fix last
> night after reading your response on the o
On Tue, 20 Aug 2024 00:01:02 -0400 Mina Almasry wrote:
> Took a bit of a look here. Forgive me, I'm not that familiar with XDP
> and virtual interfaces, so I'm a bit unsure what to do here.
>
> For veth, it seems, the device behind the veth is stored in
> veth_priv->peer, so it seems maybe a dev_g
On Mon, 19 Aug 2024 00:44:27 +0900 Taehee Yoo wrote:
> > @@ -9537,6 +9540,10 @@ static int dev_xdp_attach(struct net_device *dev,
> > struct netlink_ext_ack *extack
> > NL_SET_ERR_MSG(extack, "Native and generic XDP
> > can't be active at the same time");
> >
On Mon, 19 Aug 2024 16:38:32 -0400 Mina Almasry wrote:
> Looks like in this iteration I resolved the previous test failure, but
> introduced a build regression with certain configs:
>
> ld: vmlinux.o: in function `netdev_rx_queue_restart':
> (.text+0x6a4133): undefined reference to `page_pool_chec
On Fri, 16 Aug 2024 08:20:44 -0400 Mina Almasry wrote:
> > I'd keep the current check with a WARN_ON_ONCE(), tho.
> > Given the absence of tests driver developers can use.
> > Especially those who _aren't_ supporting the feature.
>
> Yes what I have locally is the driver setting
> netdev_rx_queue-
On Wed, 14 Aug 2024 17:32:53 +0100 Pavel Begunkov wrote:
> > This is where I get a bit confused. Jakub did mention that it is
> > desirable for core to verify that the driver did the right thing,
> > instead of trusting that a driver did the right thing without
> > verifying. Relying on a flag from
On Tue, 13 Aug 2024 21:13:08 + Mina Almasry wrote:
> +EXPORT_SYMBOL(page_pool_mem_providers);
not sure if this export is needed, but it doesn't appear to be needed
by this patch?
On Tue, 13 Aug 2024 21:13:05 + Mina Almasry wrote:
> + if (NL_REQ_ATTR_CHECK(info->extack, attr, tb,
> + NETDEV_A_QUEUE_ID)) {
> + err = -EINVAL;
> + goto err_unlock;
> + }
> +
> + if (
On Tue, 13 Aug 2024 21:13:05 + Mina Almasry wrote:
> +int dev_get_max_mp_channel(const struct net_device *dev)
> +{
> + int i, max = -1;
I presume the bug from yesterday is self evident once reported? :)
> + ASSERT_RTNL();
> +
> + for (i = 0; i < dev->real_num_rx_queues; i++)
> +
On Tue, 13 Aug 2024 21:13:02 + Mina Almasry wrote:
> v18 got a thorough review (thanks!), and this iteration addresses the
> feedback.
>
> Major changes:
> - Prevent deactivating mp bound queues.
> - Prevent installing xdp on mp bound netdevs, or installing mps on xdp
> installed netdevs.
>
On Tue, 13 Aug 2024 16:11:15 +0100 Pavel Begunkov wrote:
> On 8/13/24 15:39, Jakub Kicinski wrote:
> > On Tue, 13 Aug 2024 03:31:13 +0100 Pavel Begunkov wrote:
> >> I'm getting lost, so repeating myself a bit. What I think
> >> would be a good approach is if we
On Tue, 13 Aug 2024 03:31:13 +0100 Pavel Begunkov wrote:
> I'm getting lost, so repeating myself a bit. What I think
> would be a good approach is if we get an error back from
> the driver if it doesn't support netiov / providers.
>
> netdev_rx_queue_restart() {
> ...
> err = dev->queu
On Tue, 13 Aug 2024 04:39:47 -0400 Mina Almasry wrote:
> On Mon, Aug 12, 2024 at 8:15 PM Jakub Kicinski wrote:
> > BTW, Mina, the core should probably also check that XDP isn't installed
> > before / while the netmem is bound to a queue.
>
> Sorry if noob question, bu
On Mon, 12 Aug 2024 20:04:41 +0100 Pavel Begunkov wrote:
> >> Also don't see the upside of the explicit "non-capable" flag,
> >> but I haven't thought of that. Is there any use?
>
> Or maybe I don't get what you're asking, I explained
> why to have that "PP_IGNORE_PROVIDERS" on top of the flag
>
On Mon, 12 Aug 2024 20:10:39 +0100 Pavel Begunkov wrote:
> > 1. Drivers need to be able to say "I support unreadable netmem".
> > Failure to report unreadable netmem support should cause the netlink
> > API to fail when the user tries to bind dmabuf/io uring memory.
> >
> > 2. Drivers need to be a
On Sun, 11 Aug 2024 22:51:13 +0100 Pavel Begunkov wrote:
> > I think we're talking about 2 slightly different flags, AFAIU.>
> > Pavel and I are suggesting the driver reports "I support memory
> > providers" directly to core (via the queue-api or what not), and we
> > check that flag directly in ne
On Fri, 9 Aug 2024 16:45:50 +0100 Pavel Begunkov wrote:
> > I think this is good, and it doesn't seem hacky to me, because we can
> > check the page_pools of the netdev while we hold rtnl, so we can be
> > sure nothing is messing with the pp configuration in the meantime.
> > Like you say below it
On Thu, 8 Aug 2024 16:36:24 -0400 Mina Almasry wrote:
> > How do you know that the driver:
> > - supports net_iov at all (let's not make implicit assumptions based
> >on presence of queue API);
> > - supports net_iov in current configuration (eg header-data split is
> >enabled)
> > - sup
On Mon, 5 Aug 2024 21:25:20 + Mina Almasry wrote:
> + if (pool->p.queue) {
> + /* We rely on rtnl_lock()ing to make sure netdev_rx_queue
> + * configuration doesn't change while we're initializing the
> + * page_pool.
> + */
> +
On Mon, 5 Aug 2024 21:25:17 + Mina Almasry wrote:
> +struct net_iov *
> +net_devmem_alloc_dmabuf(struct net_devmem_dmabuf_binding *binding)
> +{
> + struct dmabuf_genpool_chunk_owner *owner;
> + unsigned long dma_addr;
> + struct net_iov *niov;
> + ssize_t offset;
> + ssize
On Mon, 5 Aug 2024 21:25:18 + Mina Almasry wrote:
> +dma_addr_t page_pool_get_dma_addr_netmem(netmem_ref netmem)
> +{
> + struct page *page = netmem_to_page(netmem);
> +
> + dma_addr_t ret = page->dma_addr;
> +
> + if (PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA)
> + ret <<= PA
On Mon, 5 Aug 2024 21:25:16 + Mina Almasry wrote:
> +/* Protected by rtnl_lock() */
> +static DEFINE_XARRAY_FLAGS(net_devmem_dmabuf_bindings, XA_FLAGS_ALLOC1);
nit: global variable declarations before any code
> +void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding)
> +{
>
On Thu, 11 Jul 2024 13:57:01 -0700 Mina Almasry wrote:
> > > Sorry none of those are only used by net/core/*. Pretty much all of
> > > these are used by include/net/page_pool/helpers.h, and some have
> > > callers in net/core/devmem.c or net/core/skbuff.c
> > >
> > > Would you like me to move these
On Wed, 10 Jul 2024 00:17:46 + Mina Almasry wrote:
> Add dmabuf information to page_pool stats:
>
> $ ./cli.py --spec ../netlink/specs/netdev.yaml --dump page-pool-get
Aha, thanks!
Reviewed-by: Jakub Kicinski
On Wed, 10 Jul 2024 16:42:04 -0700 Mina Almasry wrote:
> > > +static inline void netmem_set_pp(netmem_ref netmem, struct page_pool
> > > *pool)
> > > +{
> > > + __netmem_clear_lsb(netmem)->pp = pool;
> > > +}
> >
> > Why is all this stuff in the main header? It's really low level.
> > Please
On Wed, 10 Jul 2024 13:29:03 -0700 Mina Almasry wrote:
> If we want to add __skb_frag_ref() support for net_iov I suggest something
> like:
>
> diff --git a/include/linux/skbuff_ref.h b/include/linux/skbuff_ref.h
> index 0f3c58007488a..02f7f4c7d4821 100644
> --- a/include/linux/skbuff_ref.h
> +++
On Wed, 10 Jul 2024 12:29:58 -0700 Mina Almasry wrote:
> On Wed, Jul 10, 2024 at 9:37 AM Jakub Kicinski wrote:
> > On Wed, 10 Jul 2024 00:17:37 + Mina Almasry wrote:
> > > + net_devmem_dmabuf_binding_get(binding);
> >
> > Why does every iov need to hold
On Wed, 10 Jul 2024 00:17:38 + Mina Almasry wrote:
> @@ -68,17 +107,103 @@ static inline netmem_ref page_to_netmem(struct page
> *page)
>
> static inline int netmem_ref_count(netmem_ref netmem)
> {
> + /* The non-pp refcount of net_iov is always 1. On net_iov, we only
> + * suppor
On Wed, 10 Jul 2024 00:17:37 + Mina Almasry wrote:
> + net_devmem_dmabuf_binding_get(binding);
Why does every iov need to hold a ref? pp holds a ref and does its own
accounting, so it won't disappear unless all the pages are returned.
On Wed, 10 Jul 2024 00:17:36 + Mina Almasry wrote:
> + err = gen_pool_add_owner(binding->chunk_pool, dma_addr,
> + dma_addr, len, dev_to_node(&dev->dev),
> + owner);
> + if (err) {
kfree(o
On Wed, 10 Jul 2024 00:17:35 + Mina Almasry wrote:
> API takes the dma-buf fd as input, and binds it to the netdevice. The
> user can specify the rx queues to bind the dma-buf to.
>
> Suggested-by: Stanislav Fomichev
> Signed-off-by: Mina Almasry
Reviewed-by: Jakub Kicinski
On Wed, 10 Jul 2024 00:17:34 + Mina Almasry wrote:
> + DEBUG_NET_WARN_ON_ONCE(!rtnl_is_locked());
ASSERT_RTNL() ?
On Wed, 3 Jul 2024 09:56:45 -0700 Mina Almasry wrote:
> > Is this really sufficient in terms of locking? @binding is not
> > RCU-protected and neither is the reader guaranteed to be in
> > an RCU critical section. Actually the "reader" tries to take a ref
> > and use this struct so it's not even a
On Fri, 28 Jun 2024 00:32:37 + Mina Almasry wrote:
> v15:
> https://patchwork.kernel.org/project/netdevbpf/list/?series=865481&state=*
I'll pick up a couple of patches unlikely to change.
On Fri, 28 Jun 2024 00:32:40 + Mina Almasry wrote:
> +/* Protected by rtnl_lock() */
> +static DEFINE_XARRAY_FLAGS(net_devmem_dmabuf_bindings, XA_FLAGS_ALLOC1);
> +
> +void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding)
> +{
> + struct netdev_rx_queue *rxq;
> + unsi
On Fri, 28 Jun 2024 00:32:39 + Mina Almasry wrote:
> API takes the dma-buf fd as input, and binds it to the netdevice. The
> user can specify the rx queues to bind the dma-buf to.
>
> Suggested-by: Stanislav Fomichev
> Signed-off-by: Mina Almasry
> diff --git a/Documentation/netlink/specs/n
On Fri, 28 Jun 2024 00:32:38 + Mina Almasry wrote:
> Add netdev_rx_queue_restart() function to netdev_rx_queue.h
>
> Signed-off-by: David Wei
> Signed-off-by: Mina Almasry
> Reviewed-by: Pavel Begunkov
Reviewed-by: Jakub Kicinski
On Thu, 27 Jun 2024 13:36:57 -0700 Mina Almasry wrote:
> `make -C ./tools/testing/selftests/net TARGETS=ncdevmem`, which works.
AFAIU the most supported incantation would have to be something rather
insane, like:
make -C tools/testing/selftests TARGETS=net
TEST_GEN_PROGS="$(pwd)/tools/testing/se
On Thu, 27 Jun 2024 12:55:38 -0700 Mina Almasry wrote:
> `git clean -fdx && make headers_install && make -C
> ./tools/testing/selftests/net` works
>
> `git clean -fdx && make headers_install && make -C
> ./tools/testing/selftests/net ncdevmem` doesn't work with this error:
Hm, I haven't tested
On Wed, 26 Jun 2024 15:08:22 -0700 Jakub Kicinski wrote:
> On Tue, 25 Jun 2024 19:54:01 + Mina Almasry wrote:
> > +CFLAGS += -I../../../net/ynl/generated/
> > +CFLAGS += -I../../../net/ynl/lib/
> > +
> > +LDLIBS += ../../../net/ynl/lib/ynl.a ../../../net/ynl/gener
On Tue, 25 Jun 2024 19:54:01 + Mina Almasry wrote:
> +CFLAGS += -I../../../net/ynl/generated/
> +CFLAGS += -I../../../net/ynl/lib/
> +
> +LDLIBS += ../../../net/ynl/lib/ynl.a ../../../net/ynl/generated/protos.a
Not as easy as this.. Please add this commit to your series:
https://github.com/kub
On Tue, 25 Jun 2024 07:16:00 -0700 Mina Almasry wrote:
> What happened here is that I sync'd to net-next, ran all the tests
> including the allmodconfig build which took a few hours, then posted
> the series. In the meantime 34 patches got merged to net-next, and one
> of those patches seems to gen
On Thu, 20 Jun 2024 08:43:34 + Omer Shpigelman wrote:
> > You support 400G, you really need to give the user the ability
> > to access higher pages.
>
> Actually the 200G and 400G modes in the ethtool code should be removed
> from this patch set. They are not relevant for Gaudi2. I'll fix it
On Wed, 19 Jun 2024 07:16:20 + Omer Shpigelman wrote:
> >> Are you referring to get_module_eeprom_by_page()? if so, then it is not
> >> supported by our FW, we read the entire data on device load.
> >> However, I can hide that behind the new API and return only the
> >> requested page if that's
On Thu, 13 Jun 2024 01:35:37 + Mina Almasry wrote:
> v12:
> https://patchwork.kernel.org/project/netdevbpf/list/?series=859747&state=*
patches 5 and 6 transiently break the build
../include/trace/events/page_pool.h:65:23: error: use of undeclared identifier
'NET_IOV'
65 |
On Fri, 7 Jun 2024 00:51:15 + Mina Almasry wrote:
> Abstrace the memory type from the page_pool so we can later add support
> for new memory types. Convert the page_pool to use the new netmem type
> abstraction, rather than use struct page directly.
>
> As of this patch the netmem type is a n
On Wed, 29 May 2024 02:19:47 +0800 kernel test robot wrote:
> | `--
> net-ipv6-route.c-rt6_fill_node()-error:we-previously-assumed-dst-could-be-null-(see-line-)
Is there a way for us to mark this as false positive?
On Fri, 3 May 2024 20:25:49 +0300 Tomi Valkeinen wrote:
> > I think the second patch also needs to go to drm-misc-next-fixes? The
> > clang warning fixed by it has returned in next-20240503 because it
> > appears that for-linux-next was switch from drm-misc-next to
> > drm-misc-next-fixes, as I see
On Fri, 10 May 2024 16:21:11 -0700 Mina Almasry wrote:
> Device Memory TCP
Sorry Mina, this is too big to apply during the merge window :(
--
pw-bot: defer
On Tue, 30 Apr 2024 17:38:09 + Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbangi
On Wed, 10 Apr 2024 16:02:00 +0200 Julien Panis wrote:
> > You shouldn't build the skb upfront any more. Give the page to the HW,
> > once HW sends you a completion - build the skbs. If build fails
> > (allocation failure) just give the page back to HW. If it succeeds,
> > however, you'll get a skb
On Wed, 10 Apr 2024 10:36:16 +0200 Julien Panis wrote:
> Also, about mem alloc failures, shouldn't we free 'pool' on kstrdup_const()
> error at the beginning of k3_cppi_desc_pool_create_name() ?
> I mean, it's not visible in my patch but I now wonder if this was done
> properly even before I modify
On Mon, 08 Apr 2024 11:38:04 +0200 Julien Panis wrote:
> +static struct sk_buff *am65_cpsw_alloc_skb(struct am65_cpsw_rx_chn *rx_chn,
> +struct net_device *ndev,
> +unsigned int len,
> +
On Mon, 08 Apr 2024 11:38:03 +0200 Julien Panis wrote:
> goto gen_pool_create_fail;
> }
>
> + pool->desc_infos = kcalloc(pool->num_desc,
> +sizeof(*pool->desc_infos), GFP_KERNEL);
> + if (!pool->desc_infos) {
> + ret = -ENOME
On Wed, 3 Apr 2024 06:19:27 -0700 Guenter Roeck wrote:
> dev_addr_lists_test generates lock warning noise at the end of tests
> if lock debugging is enabled. There are two sets of warnings.
>
> WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923
> __mutex_unlock_slowpath.constprop.0+0x13c/0x3
On Tue, 26 Mar 2024 23:37:59 +0100 Arnd Bergmann wrote:
> I hope that the patches can get picked up by platform maintainers
> directly, so the final patch can go in later on.
platform == subsystem? :)
On Fri, 22 Mar 2024 10:40:26 -0700 Mina Almasry wrote:
> Other designs for this hugepage use case are possible, I'm just
> describing Jakub's idea for it as a potential use-case for these
> hooks.
I made it ops because I had 4 different implementations with different
recycling algorithms. I think
On Mon, 4 Mar 2024 18:01:40 -0800 Mina Almasry wrote:
> + if (!dev || !dev->netdev_ops)
> + return -EINVAL;
too defensive
> + if (!dev->netdev_ops->ndo_queue_stop ||
> + !dev->netdev_ops->ndo_queue_mem_free ||
> + !dev->netdev_ops->ndo_queue_mem_alloc ||
> +
On Thu, 7 Mar 2024 18:08:24 -0800 Mina Almasry wrote:
> On Thu, Mar 7, 2024 at 5:30 PM Jakub Kicinski wrote:
> > On Mon, 4 Mar 2024 18:01:36 -0800 Mina Almasry wrote:
> > > + * void *(*ndo_queue_mem_alloc)(struct net_device *dev, int idx);
> > > + * Allocate
On Mon, 4 Mar 2024 18:01:49 -0800 Mina Almasry wrote:
> +Intro
> +=
> +
> +Device memory TCP (devmem TCP) enables receiving data directly into device
> +memory (dmabuf). The feature is currently implemented for TCP sockets.
> +
> +
> +Opportunity
> +---
> +
> +A large amount of data tr
On Mon, 4 Mar 2024 18:01:36 -0800 Mina Almasry wrote:
> + * void *(*ndo_queue_mem_alloc)(struct net_device *dev, int idx);
> + * Allocate memory for an RX queue. The memory returned in the form of
> + * a void * can be passed to ndo_queue_mem_free() for freeing or to
> + * ndo_queue_start to
On Thu, 7 Dec 2023 16:52:36 -0800 Mina Almasry wrote:
> +name: type
> +doc: rx or tx queue
> +type: u8
> +enum: queue-type
nit: the queue/napi GET was applied to net-next, would be good to stick
to the same types (s/u8/u32)
On Thu, 7 Dec 2023 16:52:34 -0800 Mina Almasry wrote:
> This API enables the net stack to reset the queues used for devmem.
Nice, thanks for moving this forward. FWIW when I started hacking on it
the API looked more like:
https://github.com/kuba-moo/linux/commit/7af8abfa4fdff248e21fc76aecc334004a
On Sun, 12 Nov 2023 20:08:10 -0800 Mina Almasry wrote:
> 1. For (b), would it be OK to implement a very minimal version of
> queue_[stop|start]/queue_mem_[alloc|free], which I use for the sole
> purpose of reposting buffers to an individual queue, and then later
> whoever picks up your queue API ef
On Sun, 12 Nov 2023 22:05:30 -0800 Mina Almasry wrote:
> My issue here is that all these skb helpers call each other so I end
> up having to move a lot of the unrelated skb helpers to this new
> header (maybe that is acceptable but it feels weird).
Splitting pp headers again is not an option, we a
On Sun, 12 Nov 2023 19:28:52 -0800 Mina Almasry wrote:
> My issue with this is that if the driver doesn't support dmabuf then
> the driver will accidentally use the pp backed by the dmabuf, allocate
> a page from it, then call page_address() on it or something, and
> crash.
>
> Currently I avoid t
On Fri, 10 Nov 2023 18:27:08 -0800 Mina Almasry wrote:
> Thanks for the clear requirement. I clearly had something different in mind.
>
> Might be dumb suggestions, but instead of creating a new ndo that we
> maybe end up wanting to deprecate once the queue API is ready, how
> about we use either
1 - 100 of 156 matches
Mail list logo
