From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 18:18:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFE21065678; Tue, 24 Jul 2012 18:18:29 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCB328FC17; Tue, 24 Jul 2012 18:18:28 +0000 (UTC) Received: by weyx56 with SMTP id x56so6393104wey.13 for ; Tue, 24 Jul 2012 11:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5yPXMt57VKKDGr2n4lrETE0gqk+WFMPKx9D932NKZoM=; b=JaGAzk7/LdBaVT0OdN8HwxNHjHu3ufducSkjyYwjKqqL7nP129agDNbcb8Y2vmtGwG d2vQ1nLKlgS6WOL/AckdP7FjRdrzo3Io6RIhgAAkaIJMTC8GHwpGYGval8hdYqOo7LTr ugEgKq+Gs3m6aWlfH6DdhJ9G04MZ043/ao6LqK5r/cPCA48vTVYodm1g/pW7JeWLAaxP HfCE7tyh1sJn+jaLWhzYWco+qDNR3JP3kYTM143XGwGLtxempiU1hRFmRUluRpLQi3fp ynkRyIJdUgNtU9XwT012l844Wq4C5BF2tIHnduK/S4BTkO1fHZ+GY5C7SiTIBSkh+ZPc WuUA== MIME-Version: 1.0 Received: by 10.180.78.33 with SMTP id y1mr9232694wiw.3.1343153907921; Tue, 24 Jul 2012 11:18:27 -0700 (PDT) Received: by 10.216.79.81 with HTTP; Tue, 24 Jul 2012 11:18:27 -0700 (PDT) Date: Tue, 24 Jul 2012 14:18:27 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Net Content-Type: multipart/mixed; boundary=f46d043bdec88f754c04c5976376 Cc: FreeBSD Hackers Subject: Generic queue's KPI to manipulate mbuf's queue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:18:29 -0000 --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 , 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 ... 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 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--