Generic queue's KPI to manipulate mbuf's queue

[Andre Oppermann]

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.

> 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.

-- 
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"
>