netdev - Re: [PATCH] NET: Multiqueue network device support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jun 2007 07:48:27 -0400
From:	jamal <hadi@...erus.ca>
To:	Zhu Yi <yi.zhu@...el.com>
Cc:	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.

Hi Yi,

On Thu, 2007-14-06 at 10:44 +0800, Zhu Yi wrote:
> On Wed, 2007-06-13 at 08:32 -0400, jamal wrote:
> > The key arguement i make (from day one actually) is to leave the
> > majority of the work to the driver.
> 
> But it seems not feasible the Qdisc needs to know nothing about the
> hardware rings.

This discussion is addressing whether it is feasible to do it without
the qdisc knowing anything about the hardware ring.

> > 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? 
> 
> The key to support multi-ring hardware for software is to put packets
> into hardware as much/early as possible. Guy gave a good VO vs. BK
> example. To achieve this in your model, you have to keep the TX ring
> running (in the case of PHL full) and requeue. But when there are only
> BK packets coming, you do want to stop the ring, right? AFAICS, the
> driver is not the best place to make the decision (it only knows the
> current and previous packets, but not the _next_), the Qdisc is the best
> place.
> 

I dont have much time to followup for sometime to come. I have left my
answer above. To clarify, incase i wasnt clear, I am saying:
a) It is better to have the driver change via some strategy of when to
open the tx path than trying to be generic. This shifts the burden to
the driver.
b) given the behavior of wireless media (which is very different from
wired ethernet media), you need a different strategy. In response to
Guy's question, I gave the example of being able to use management
frames to open up the tx path for VO (even when you dont know VO packets
are sitting on the qdisc); alternatively you could use a timer etc.
Theres many ways to skin the cat (with apologies to cat lovers/owners).
i.e you need to look at the media and be creative.
Peters DCE for example could also be handled by having a specific
strategy.

I will try to continue participating in the discussion (if CCed) but
much less for about a week. In any case I think i have had the
discussion i was hoping for and trust Patrick understands both sides.
This thread has run for too long folks, eh?

cheers,
jamal

-
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