Date: Thu, 24 Feb 2011 17:27:36 +0100 From: Fabien Thomas <fabien.thomas@netasq.com> To: Ryan Stone <rysto32@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Polling with multiqueue support Message-ID: <18E4F606-C361-4F10-8E58-915F28D71E42@netasq.com> In-Reply-To: <AANLkTi=R=pwXwq6Q=_kXcF=Jupg9Z331JCzpoM%2BUUHOT@mail.gmail.com> References: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> <AANLkTi=R=pwXwq6Q=_kXcF=Jupg9Z331JCzpoM%2BUUHOT@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18E4F606-C361-4F10-8E58-915F28D71E42>