On 9/28/20 7:25 AM, Magnus Karlsson wrote: > On Mon, Sep 28, 2020 at 5:13 AM David Ahern <dsah...@gmail.com> wrote: >> >> On 2/27/20 2:41 AM, Magnus Karlsson wrote: >>> I will unfortunately be after Netdevconf due to other commitments. The >>> plan is to send out the RFC to the co-authors of the Plumbers >>> presentation first, just to check the sanity of it. And after that >>> send it to the mailing list. Note that I have taken two shortcuts in >>> the RFC to be able to make quicker progress. The first on is the >>> driver implementation of the dynamic queue allocation and >>> de-allocation. It just does this within a statically pre-allocated set >>> of queues. The second is that the user space interface is just a >>> setsockopt instead of a rtnetlink interface. Again, just to save some >>> time in this initial phase. The information communicated in the >>> interface is the same though. In the current code, the queue manager >>> can handle the queues of the networking stack, the XDP_TX queues and >>> queues allocated by user space and used for AF_XDP. Other uses from >>> user space is not covered due to my setsockopt shortcut. Hopefully >>> though, this should be enough for an initial assessment. >> >> Any updates on the RFC? I do not recall seeing a patch set on the >> mailing list, but maybe I missed it. > > No, you have unfortunately not missed anything. It has been lying on > the shelf collecting dust for most of this time. The reason was that > the driver changes needed to support dynamic queue allocation just > became too complex as it would require major surgery to at least all > Intel drivers, and probably a large number of other ones as well. Do > not think any vendor would support such a high effort solution and I > could not (at that time at least) find a way around it. So, gaining > visibility into what queues have been allocated (by all entities in > the kernel that uses queue) seems to be rather straightforward, but > the dynamic allocation part seems to be anything but.
retrofitting a new idea is usually a high level of effort. > > I also wonder how useful this queue manager proposal would be in light > of Mellanox's subfunction proposal. If people just start to create > many small netdevs (albeit at high cost which people may argue > against) consisting of just an rx/tx queue pair, then the queue > manager dynamic allocation proposal would not be as useful. We could > just use one of these netdevs to bind to in the AF_XDP case and always > just specify queue 0. But one can argue that queue management is > needed even for the subfunction approach, but then it would be at a > much lower level than what I proposed. What is your take on this? > Still worth pursuing in some form or another? If yes, then we really > need to come up with an easy way of supporting this in current > drivers. It is not going to fly otherwise, IMHO. > I need to find some time to take a deep dive on the subfunction idea. I like the intent, but need to understand the details. Thanks for the update.
