From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 26 01:56:59 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 2E9291065672; Thu, 26 Jul 2012 01:56:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 57C788FC0C; Thu, 26 Jul 2012 01:56:58 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so4625402wib.13 for ; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fhzF8JyuwbqS8fVrWcEZ31l1TbaG1o7MwkqNM54vAYM=; b=bx/ck+YCoSzdZdM40y+pWEKQ+WCKp0njuPN5rcCf940wWcnAfuxQsYK4dbLGhQ5xWu qF5RF21mDgPf2AxbqXhe2fmtr59HD/NXTcZCpZtHmfwpKPS+j+4mZF+CoMg9kABZyTmd Y+Mggi1G+c/h13gYJI6GTB5GY1f8V40rbwW50v0SvleJp0rkaTJ2XGAACbfPU7s9R3Vx 2oZkKDhWynfTzCQrtfOpn0uroPUtUC7yIM3in0YsH1kDL50eZuqaIVIJsoOOFLO07NMX XqFvdUTMijdxazR5/7PHdoVjxCkRvKppUUFKlX6hx27JGDXj/Gdnt6pL1NMt5t5siAwe FxwA== MIME-Version: 1.0 Received: by 10.180.84.104 with SMTP id x8mr9201281wiy.20.1343267817120; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) Received: by 10.216.227.70 with HTTP; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) In-Reply-To: <500FD7B9.4070804@freebsd.org> References: <500FD7B9.4070804@freebsd.org> Date: Wed, 25 Jul 2012 21:56:57 -0400 Message-ID: From: Arnaud Lacombe To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 26 Jul 2012 01:56:59 -0000 Hi, On Wed, Jul 25, 2012 at 7:25 AM, Andre Oppermann 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 , 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. > 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" >> >