Conversation
|
Isn't there a |
Maybe at some point, but usually the "netbuf" object will end up in stack functions, which already know how to release the packet. |
So when sending a packet this will not be used? |
I'm not sure yet. The upper layer will usually pass an iolist like object, which doesn't look like the netbuf structure. There will be indeed a function for releasing resources, but not sure yet if belongs to this netbuf API. |
|
(If we need to add a |
|
The definition of #12691 for |
|
As described in #12691 (comment), this is outdated now. I will close it |
Contribution description
This PR adds an abstraction for allocating packets from a network stack or static buffer.
The motivation behind this is:
At the same time if we want to have MAC and PHY layers that are independent to the network stack, we need an interface for allocation.
dev->driver->recv(see [RFC] netdev: change receive mechanism #11652)If CONFIG_NETBUF_DISABLE_STACK_ALLOC==0, it's necessary to define a
netbuf_stack_allocfunction for every stack.How to use
Let's assume there's a radio API for reading data from the framebuffer:
Depending on how the netbuf is initialized, it's possible to either get a buffer from the stack allocator or from a static buffer.
Let's assume GNRC has the following
netbuf_stack_allocfunction:Some examples:
Considerations about the RX procedure
I wrote this patch that overloads the "recv" function of netdev to receive a
netbufinstead of a buffer, and removed the "drop" and "get packet length" logic.The "recv" function will read the pkt_len, try to get a buffer from the netbuf and write directly to that buffer. The frame buffer is read once and the logic is simpler now.
It also makes the binary smaller from:
to
And calling
netif->ops->recv()is 6-8% faster with this method.Testing procedure
make docIssues/PRs references
It's related to the PHY/MAC rework proposed in #11483
#11652