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  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:	Fri, 27 Apr 2007 11:09:58 -0400
From:	jamal <>
To:	"Waskiewicz Jr, Peter P" <>
Cc:	Patrick McHardy <>,
	Stephen Hemminger <>,,,
	cramerj <>,
	"Kok, Auke-jan H" <>,
	"Leech, Christopher" <>,
Subject: RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote:
> > jamal wrote:
> > > On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:

> We have plans to write a new qdisc that has no priority given to any
> skb's being sent to the driver.  The reasoning for providing a
> multiqueue mode for PRIO is it's a well-known qdisc, so the hope was
> people could quickly associate with what's going on.  The other
> reasoning is we wanted to provide a way to prioritize various network
> flows (ala PRIO), and since hardware doesn't currently exist that
> provides flow prioritization, we decided to allow it to continue
> happening in software.

Reading the above validates my fears that we have some strong
differences (refer to my email to Patrick). To be fair to you, i would
have to look at your patches. Now i am actually thinking not to look at
them at all incase they influence me;->
I think the thing for me to do is provide alternative patches and then
we can have smoother discussion.
The way i see it is you dont touch any qdisc code. qdiscs that are
provided by Linux cover a majority of those provided by hardware
(Heck, I have was involved on an ethernet switch chip from your company
that provided strict prion multiqueues in hardware and didnt need to
touch the qdisc code)

> > 
> > > The driver should be configurable to be X num of queues via 
> > probably 
> > > ethtool. It should default to single ring to maintain old behavior.
> > 
> > 
> > That would probably make sense in either case.
> This shouldn't be something enforced by the OS, rather, an
> implementation detail for the driver you write.  If you want this to be
> something to be configured at run-time, on the fly, then the OS would
> need to support it.  However, I'd rather see people try the multiqueue
> support as-is first to make sure the simple things work as expected,
> then we can get into run-time reconfiguration issues (like queue
> draining if you shrink available queues, etc.).  This will also require
> some heavy lifting by the driver to tear down queues, etc.

It could be probably a module insertion/boot time operation.

> > 
> > > Ok, i see; none of those other intel people put you through 
> > the hazing 
> > > yet? ;-> This is a netdev matter - so i have taken off lkml
> > > 
> I appreciate the desire to lower clutter from mailing lists, but I see
> 'tc' as a kernel configuration utility, and as such, people should know
> what we're doing outside of netdev, IMO.  But I'm fine with keeping this
> off lkml if that's what people think.

All of netdev has to do with the kernel - that doesnt justify cross
People interested in network related subsystem development will
subscribe to netdev. Interest in scsi =. subscribe to scsi mailing lists


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists