Generic queue's KPI to manipulate mbuf's queue

[Arnaud Lacombe]

Hi,

On Wed, Jul 25, 2012 at 7:25 AM, Andre Oppermann <andre at freebsd.org> wrote:
> On 24.07.2012 20:18, Arnaud Lacombe wrote:
>>
>> Hi,
>>
>> AFAIK, there is no proper KPI for managing mbuf queue. All users have
> Before we can talk about an mbuf queue you have to define what you
> want to "queue".  Is it packets or an mbuf chain which doesn't have
> clear delimiters (as with tcp for example)?  Depending on that the
> requirements and solutions may be vastly different.
>
I was thinking about queues as in "general use-case of m_nextpkt",
that would be dummynet queuing, QoS, various reassembly queues, socket
buffer, etc...

>> to re-implements the queue logic from scratch, which is less than
>> optimal. From a preeminent FreeBSD developer at BSDCan 2009: "we do
>> not need a new list implementation". There has been a few attempt of
>> providing a queue API, namely <dev/cxgb/sys/mbufq.h>, but that is
>> nothing more than an ad-hoc solution to something which _has_to_be_
>> generic. For the sake of adding more mess in the tree, this
>> implementation has been duplicated in <dev/xen/netfront/mbufq.h>...
>
> Duplication is always a sign for the need of a generic approach/KPI.
>
>
>> Now, I understand, or at least merely witness without power, the
>> reluctance of kernel hackers to have 'struct mbuf` evolves, especially
>> wrt. their desire to keep binary compatibility of KPI[0]. Now, none of
>> the current ad-hoc API matched my needs, and I really did NOT want to
>> re-implement a new list implementation for missing basic operation,
>> such as deleting an element of the list, so I came with the attached
>> patch. The main idea is to be able to use already existing code from
>> <sys/queue.h> for mbuf queuing management. It is not the best which
>> can be done. I am not a huge fan of keeping `m_nextpkt' and
>> introducing a `m_nextelm', I would have preferred to use TAILQs, and I
>> do not like the dwelling in SLIST internal implementation details.
>> However, this change is relatively lightweight, and change neither ABI
>> or API.
>
> IMO your change is a rather elegant way of introducing the LIST macros
> to the mbuf nextpkt field.  I do like it and don't object to it providing
> you sufficiently answer the question in the first paragraph.
>
actually, I made a mistake selecting SLISTs, it should really be an
STAILQ. It has the same advantage wrt. ABI, and most usage made of
`m_nextpkt' follows a tail queue logic. The only advantage of TAILQ
would be reverse traversal, and time constant removal of inner
elements.

 - Arnaud

> --
> Andre
>
>> Any comment appreciated.
>>
>>   - Arnaud
>>
>> [0]: taking care of having a stable kernel ABI and *not* a stable
>> userland ABI is beyond my understanding, but this is not the subject
>> of this mail.
>>
>>
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>