Message ID | 20141003104858.6745.62964.stgit@dragon |
---|---|
State | Rejected, archived |
Delegated to: | David Miller |
Headers | show |
On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer <brouer@redhat.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? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 3 Oct 2014 09:53:16 -0700 Cong Wang <cwang@twopensource.com> wrote: > On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer > <brouer@redhat.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.
On Fri, Oct 3, 2014 at 1:38 PM, Jesper Dangaard Brouer <brouer@redhat.com> wrote: > On Fri, 3 Oct 2014 09:53:16 -0700 > Cong Wang <cwang@twopensource.com> wrote: > >> On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer >> <brouer@redhat.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. I wish you are right, but this really worries me... http://marc.info/?l=linux-netdev&m=137516888117465&w=2 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@twopensource.com> wrote: > > > On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer > > <brouer@redhat.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Fri, 03 Oct 2014 13:51:59 -0700 > 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@twopensource.com> wrote: >> >> > On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer >> > <brouer@redhat.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. Agreed, this change cannot be made. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/veth.c b/drivers/net/veth.c index 8ad5965..3c32fcf 100644 --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -287,6 +287,7 @@ static const struct net_device_ops veth_netdev_ops = { static void veth_setup(struct net_device *dev) { ether_setup(dev); + dev->tx_queue_len = 0; dev->priv_flags &= ~IFF_TX_SKB_SHARING; dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
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. Reported-by: Mrunal Patel <mpatel@redhat.com> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> --- drivers/net/veth.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html