From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 11:32:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ABB7106566B for ; Wed, 25 Jul 2012 11:32:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 922FA8FC0A for ; Wed, 25 Jul 2012 11:32:32 +0000 (UTC) Received: (qmail 83650 invoked from network); 25 Jul 2012 13:20:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jul 2012 13:20:14 -0000 Message-ID: <500FD7B9.4070804@freebsd.org> Date: Wed, 25 Jul 2012 13:25:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , FreeBSD Hackers Subject: Re: Generic queue's KPI to manipulate mbuf's queue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:32:33 -0000 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 , 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 ... 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 > 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >