[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18031.60741.695897.572432@robur.slu.se>
Date: Wed, 13 Jun 2007 15:12:37 +0200
From: Robert Olsson <Robert.Olsson@...a.slu.se>
To: hadi@...erus.ca
Cc: Zhu Yi <yi.zhu@...el.com>, Patrick McHardy <kaber@...sh.net>,
David Miller <davem@...emloft.net>,
peter.p.waskiewicz.jr@...el.com, netdev@...r.kernel.org,
jeff@...zik.org, auke-jan.h.kok@...el.com
Subject: Re: [PATCH] NET: Multiqueue network device support.
jamal writes:
> The key arguement i make (from day one actually) is to leave the
> majority of the work to the driver.
> My view of wireless WMM etc is it is a different media behavior
> (compared to wired ethernet) which means a different view of strategy
> for when it opens the valve to allow in more packets. 802.11 media has
> embedded signalling which is usable. Guy Cohen gave a good use case
> which i responded to. Do you wanna look at that and respond?
Hello,
Haven't got all details. IMO we need to support some "bonding-like"
scenario too. Where one CPU is feeding just one TX-ring. (and TX-buffers
cleared by same CPU). We probably don't want to stall all queuing when
when one ring is full.
The scenario I see is to support parallelism in forwarding/firewalling etc.
For example when RX load via HW gets split into different CPU's and for
cache reasons we want to process in same CPU even with TX.
If RX HW split keeps packets from the same flow on same CPU we shouldn't
get reordering within flows.
Cheers
--ro
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists