netdev - Re: [ofa-general] Re: [PATCH 2/3][NET

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 9 Oct 2007 11:22:25 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	johnpol@....mipt.ru, herbert@...dor.apana.org.au,
	gaagaan@...il.com, Robert.Olsson@...a.slu.se,
	netdev@...r.kernel.org, rdreier@...co.com,
	peter.p.waskiewicz.jr@...el.com, hadi@...erus.ca,
	mcarlson@...adcom.com, jagana@...ibm.com,
	general@...ts.openfabrics.org, mchan@...adcom.com, tgraf@...g.ch,
	randy.dunlap@...cle.com, sri@...ibm.com, kaber@...sh.net
Subject: Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching

On 09 Oct 2007 18:51:51 +0200
Andi Kleen <andi@...stfloor.org> wrote:

> David Miller <davem@...emloft.net> writes:
> > 
> > 2) Switch the default qdisc away from pfifo_fast to a new DRR fifo
> >    with load balancing using the code in #1.  I think this is kind
> >    of in the territory of what Peter said he is working on.
> 
> Hopefully that new qdisc will just use the TX rings of the hardware
> directly. They are typically large enough these days. That might avoid
> some locking in this critical path.
> 
> >    I know this is controversial, but realistically I doubt users
> >    benefit at all from the prioritization that pfifo provides.
> 
> I agree. For most interfaces the priority is probably dubious.
> Even for DSL the prioritization will be likely usually done in a router
> these days.
> 
> Also for the fast interfaces where we do TSO priority doesn't work
> very well anyways -- with large packets there is not too much 
> to prioritize.
> 
> > 3) Work on discovering a way to make the locking on transmit as
> >    localized to the current thread of execution as possible.  Things
> >    like RCU and statistic replication, techniques we use widely
> >    elsewhere in the stack, begin to come to mind.
> 
> If the data is just passed on to the hardware queue, why is any 
> locking needed at all? (except for the driver locking of course)
> 
> -Andi

I wonder about the whole idea of queueing in general at such high speeds.
Given the normal bi-modal distribution of packets, and the predominance
of 1500 byte MTU; does it make sense to even have any queueing in software
at all?


-- 
Stephen Hemminger <shemminger@...ux-foundation.org>
-
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