Date: Wed, 25 Jul 2012 21:56:57 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Andre Oppermann <andre@freebsd.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Generic queue's KPI to manipulate mbuf's queue Message-ID: <CACqU3MXjA3nSNuUCCK%2BCc=PtxVyWAOxf%2BTberQvjgiQg1OVxWA@mail.gmail.com> In-Reply-To: <500FD7B9.4070804@freebsd.org> References: <CACqU3MW1cOSQcocR3QSTNYYYvBMu_ndmk%2Byp2M%2Bo=H0aCMPPTg@mail.gmail.com> <500FD7B9.4070804@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Wed, Jul 25, 2012 at 7:25 AM, Andre Oppermann <andre@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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MXjA3nSNuUCCK%2BCc=PtxVyWAOxf%2BTberQvjgiQg1OVxWA>