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  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, 11 Aug 2015 17:48:07 +0200
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	phil@....cc, fw@...len.de, netdev@...r.kernel.org,
	cwang@...pensource.com, eric.dumazet@...il.com, brouer@...hat.com
Subject: Re: [net-next PATCH 1/3] net: make default tx_queue_len
 configurable


On Wed, 29 Jul 2015 14:37:31 -0700 (PDT) David Miller <davem@...emloft.net> wrote:
[...]
> Which is that there are devices (virtual or whatever) which don't want
> a qdisc attached no matter what.  Flag those devices as such and
> adjust the qdisc attachment logic to check that new flag.

I agree on the approach DaveM are suggesting.

But virtual devices must support getting a qdisc attached.  I know of
many companies depending on this behavior.   Some times people just get
hit by this "strange" zero len issues when they happen to use
pfifo_fast as leaf node.


> Anything is better than hacking the queue len.

The hole problem comes from the double meaning of the queue len. e.g.
that value 0 have special meaning, but only during assigning the
default qdisc.  And pfifo_fast will use queue len zero if assigned.

(proposed solution:)

As DaveM also suggested, I would likely use a device flag to indicate
the device does not require any qdisc, and not assign any qdisc
(actually "noqueue") in case the default qdisc is chosen for this
device.

This should solve the problem for veth. And then we should cleanup all
the virtual devices, adding this flag and changing the
dev->tx_queue_len to the default value (e.g. remove setting it to zero).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer
--
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