# Re: \[RFC PATCH v2 02/11\] netdev: implement netlink api to bind dma-buf to netdevice

- From: David Ahern \<dsahern@kernel.org\>
- Date: 2023-08-18 02:21:50 
- List: netdev
- Page: https://ratatoskr.run/netdev/2023/08/11269912
- Thread: https://ratatoskr.run/netdev/2023/08/8452614/t.md

```text
On 8/17/23 8:09 PM, Jakub Kicinski wrote:
>>
>> Flow steering to TC offloads -- more details on what you were thinking here?
> 
> I think TC flower can do almost everything ethtool -N can.
> So do we continue to developer for both APIs or pick one?

ok, tc flower; that did not come to mind. Don't use it often.

> 
>>>> I don't have a good sense of what a good model for cleanup and
>>>> permissions is (B). All I know is that if we need to tie things to
>>>> processes netlink can do it, and we shouldn't have to create our
>>>> own FS and special file descriptors...  
>>
>> From my perspective the main sticking point that has not been handled is
>> flushing buffers from the RxQ, but there is 100% tied to queue
>> management and a process' ability to effect a flush or queue tear down -
>> and that is the focus of your list below:
> 
> If you're thinking about it from the perspective of "application died
> give me back all the buffers" - the RxQ is just one piece, right?
> As we discovered with page pool - packets may get stuck in stack for
> ever.

Yes, flushing the retransmit queue for TCP is one of those places where
buffer references can get stuck for some amount of time.

>>
>> `ethtool -L/-G` and `ip link set {up/down}` pertain to the "general OS"
>> queues managed by a driver for generic workloads and networking
>> management (e.g., neigh discovery, icmp, etc). The discussions here
>> pertains to processes wanting to use their own memory or GPU memory in a
>> queue. Processes will come and go and the queue management needs to
>> align with that need without affecting all of the other queues managed
>> by the driver.
> 
> For sure, I'm just saying that both the old uAPI can be translated to
> the new driver API, and so should the new uAPIs. I focused on the
> driver facing APIs because I think that it's the hard part. We have
> many drivers, the uAPI is more easily dreamed up, no?

sure.


```