Date: Tue, 24 Jul 2012 14:18:27 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: FreeBSD Net <freebsd-net@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Generic queue's KPI to manipulate mbuf's queue Message-ID: <CACqU3MW1cOSQcocR3QSTNYYYvBMu_ndmk%2Byp2M%2Bo=H0aCMPPTg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--f46d043bdec88f754c04c5976376 Content-Type: text/plain; charset=ISO-8859-1 Hi, AFAIK, there is no proper KPI for managing mbuf queue. All users have 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>... 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. 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. --f46d043bdec88f754c04c5976376 Content-Type: application/octet-stream; name="mbuf_slist.diff" Content-Disposition: attachment; filename="mbuf_slist.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h51aq8mx0 ZGlmZiAtLWdpdCBhL2ZyZWVic2Qvc3lzL3N5cy9tYnVmLmggYi9mcmVlYnNkL3N5cy9zeXMvbWJ1 Zi5oCmluZGV4IDkwN2I3N2EuLmVhOWFmZWIgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvbWJ1Zi5oCisr KyBiL3N5cy9zeXMvbWJ1Zi5oCkBAIC04OCw3ICs4OCw3IEBAIHN0cnVjdCBtYl9hcmdzIHsKICAq Lwogc3RydWN0IG1faGRyIHsKIAlzdHJ1Y3QgbWJ1ZgkqbWhfbmV4dDsJLyogbmV4dCBidWZmZXIg aW4gY2hhaW4gKi8KLQlzdHJ1Y3QgbWJ1ZgkqbWhfbmV4dHBrdDsJLyogbmV4dCBjaGFpbiBpbiBx dWV1ZS9yZWNvcmQgKi8KKwlTTElTVF9FTlRSWShtYnVmKSBtaF9uZXh0cGt0OwkvKiBuZXh0IGNo YWluIGluIHF1ZXVlL3JlY29yZCAqLwogCWNhZGRyX3QJCSBtaF9kYXRhOwkvKiBsb2NhdGlvbiBv ZiBkYXRhICovCiAJaW50CQkgbWhfbGVuOwkvKiBhbW91bnQgb2YgZGF0YSBpbiB0aGlzIG1idWYg Ki8KIAlpbnQJCSBtaF9mbGFnczsJLyogZmxhZ3M7IHNlZSBiZWxvdyAqLwpAQCAtMTU5LDcgKzE1 OSw4IEBAIHN0cnVjdCBtYnVmIHsKICNkZWZpbmUJbV9kYXRhCQltX2hkci5taF9kYXRhCiAjZGVm aW5lCW1fdHlwZQkJbV9oZHIubWhfdHlwZQogI2RlZmluZQltX2ZsYWdzCQltX2hkci5taF9mbGFn cwotI2RlZmluZQltX25leHRwa3QJbV9oZHIubWhfbmV4dHBrdAorI2RlZmluZQltX25leHRwa3QJ bV9oZHIubWhfbmV4dHBrdC5zbGVfbmV4dAorI2RlZmluZQltX25leHRlbG0JbV9oZHIubWhfbmV4 dHBrdAogI2RlZmluZQltX2FjdAkJbV9uZXh0cGt0CiAjZGVmaW5lCW1fcGt0aGRyCU1fZGF0Lk1I Lk1IX3BrdGhkcgogI2RlZmluZQltX2V4dAkJTV9kYXQuTUguTUhfZGF0Lk1IX2V4dAo= --f46d043bdec88f754c04c5976376--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MW1cOSQcocR3QSTNYYYvBMu_ndmk%2Byp2M%2Bo=H0aCMPPTg>