netdev - Re: [net-next PATCH] veth: don't assign a qdisc to veth

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]

Message-ID: <1412369519.17245.2.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Fri, 03 Oct 2014 13:51:59 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jesper Dangaard Brouer <brouer@...hat.com>
Cc:	Cong Wang <cwang@...pensource.com>,
	netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jiri Pirko <jpirko@...hat.com>, mpatel@...hat.com
Subject: Re: [net-next PATCH] veth: don't assign a qdisc to veth

On Fri, 2014-10-03 at 22:38 +0200, Jesper Dangaard Brouer wrote:
> On Fri, 3 Oct 2014 09:53:16 -0700
> Cong Wang <cwang@...pensource.com> wrote:
> 
> > On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer
> > <brouer@...hat.com> wrote:
> > > The veth driver is a virtual device, and should not have assigned
> > > the default qdisc.  Verified (ndo_start_xmit) veth_xmit can only
> > > return NETDEV_TX_OK, thus this should be safe to bypass qdisc.
> > >
> > > Not assigning a qdisc is subtly done by setting tx_queue_len to zero.
> > >
> > 
> > Huh?? Maybe your $subject is too misleading, but we do use HTB
> > on veth, this will break our code since we will have to set tx_queue_len
> > after your patch, no?
> 
> No, you HTB setup should still work.

Unfortunately no....

Default htb classes are pfifo, and this uses device txqueuelen as
default limit.

So your change should have been done years ago.

Now its too late as it can break existing user scripts.



--
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