From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 16:27:39 2011 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 46A4F106564A for ; Thu, 24 Feb 2011 16:27:39 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA068FC0A for ; Thu, 24 Feb 2011 16:27:38 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id AA444740004; Thu, 24 Feb 2011 17:26:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: Date: Thu, 24 Feb 2011 17:27:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18E4F606-C361-4F10-8E58-915F28D71E42@netasq.com> References: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> To: Ryan Stone X-Mailer: Apple Mail (2.1082) Cc: FreeBSD Net Subject: Re: Polling with multiqueue support 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: Thu, 24 Feb 2011 16:27:39 -0000 On Feb 24, 2011, at 4:39 PM, Ryan Stone wrote: > Ah, you've anticipated me. This is just the kind of thing that I had > in mind. I have some comments: Thanks for your feedback. You pushed me from my laziness to explain the patchset on the ml. :) >=20 > - Why allocate the poll_if_t in ether_poll_register_? If you let the > driver allocate it you don't have to worry about failure. And the > driver can embed it in its rx_ring so it doesn't have to worry about > malloc'ing it anyway. We can also put one it struct ifnet to preserve > the traditional ether_poll_register interface. Good point. I take it to my TODO list >=20 > - I'd personally prefer it if ether_poll_register_mq didn't require a > struct ifnet to be passed in. Nothing seems to use the ifnet anymore > and here at $(WORK) we have some non-ifnets that actually register a > polling handler. Currently they just allocate a struct ifnet to make > the polling code happy but I don't see any reason to require one. To be sure to understand using context + queue id only as identifier for = the mq part=20 and grab the ifp from the context in the driver ? That seems ok to me if it block case where you dont have ifp. >=20 > - Also, I don't quite understand why the separate TX step is necessary = now. It helps because TX is done only when every interface (on this = taskqueue,=20 cross taskqueue will require sync point) have processed packets to = completion. It can also help for the fairness between interface on the same = taskqueue to rotate faster to the next if. This is not required and can be used or not driver per driver (if not = used everything can be done on RX). There is also one fix pending for the compatibility interface: the = packet per round need to be increased because there is no feedback loop = on the old API. Fabien