Re: qdisc spin lock

2016-04-25 Thread Michael Ma
2016-04-21 15:12 GMT-07:00 Michael Ma : > 2016-04-21 5:41 GMT-07:00 Eric Dumazet : >> On Wed, 2016-04-20 at 22:51 -0700, Michael Ma wrote: >>> 2016-04-20 15:34 GMT-07:00 Eric Dumazet : >>> > On Wed, 2016-04-20 at 14:24 -0700,

Re: qdisc spin lock

2016-04-21 Thread Michael Ma
2016-04-21 5:41 GMT-07:00 Eric Dumazet : > On Wed, 2016-04-20 at 22:51 -0700, Michael Ma wrote: >> 2016-04-20 15:34 GMT-07:00 Eric Dumazet : >> > On Wed, 2016-04-20 at 14:24 -0700, Michael Ma wrote: >> >> 2016-04-08 7:19 GMT-07:00 Eric Dumazet

Re: qdisc spin lock

2016-04-21 Thread Eric Dumazet
On Wed, 2016-04-20 at 22:51 -0700, Michael Ma wrote: > 2016-04-20 15:34 GMT-07:00 Eric Dumazet : > > On Wed, 2016-04-20 at 14:24 -0700, Michael Ma wrote: > >> 2016-04-08 7:19 GMT-07:00 Eric Dumazet : > >> > On Thu, 2016-03-31 at 16:48 -0700, Michael

Re: qdisc spin lock

2016-04-20 Thread Michael Ma
2016-04-20 15:34 GMT-07:00 Eric Dumazet : > On Wed, 2016-04-20 at 14:24 -0700, Michael Ma wrote: >> 2016-04-08 7:19 GMT-07:00 Eric Dumazet : >> > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: >> >> I didn't really know that multiple qdiscs can

Re: qdisc spin lock

2016-04-20 Thread Eric Dumazet
On Wed, 2016-04-20 at 14:24 -0700, Michael Ma wrote: > 2016-04-08 7:19 GMT-07:00 Eric Dumazet : > > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: > >> I didn't really know that multiple qdiscs can be isolated using MQ so > >> that each txq can be associated with a

Re: qdisc spin lock

2016-04-20 Thread Michael Ma
2016-04-08 7:19 GMT-07:00 Eric Dumazet : > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: >> I didn't really know that multiple qdiscs can be isolated using MQ so >> that each txq can be associated with a particular qdisc. Also we don't >> really have multiple

Re: qdisc spin lock

2016-04-16 Thread Andrew
I think that it isn't a good solution - unless you can bind specified host (src/dst) to specified txq. Usually traffic is spreaded on txqs by src+dst IP (or even IP:port) hash which results in traffic spreading among all mqs on device, and wrong bandwidth limiting (N*bandwidth on multi-session

Re: qdisc spin lock

2016-04-15 Thread Eric Dumazet
On Fri, 2016-04-15 at 16:05 -0700, Michael Ma wrote: > Would definitely appreciate that. If you can share the patch it will > be helpful as well. Let me know if I can help with this... Sure, here is what I am going to test : diff --git a/drivers/net/bonding/bond_main.c

Re: qdisc spin lock

2016-04-15 Thread Michael Ma
2016-04-15 15:54 GMT-07:00 Eric Dumazet : > On Fri, 2016-04-15 at 15:46 -0700, Michael Ma wrote: >> 2016-04-08 7:19 GMT-07:00 Eric Dumazet : >> > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: >> >> I didn't really know that multiple qdiscs can

Re: qdisc spin lock

2016-04-15 Thread Eric Dumazet
On Fri, 2016-04-15 at 15:46 -0700, Michael Ma wrote: > 2016-04-08 7:19 GMT-07:00 Eric Dumazet : > > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: > >> I didn't really know that multiple qdiscs can be isolated using MQ so > >> that each txq can be associated with a

Re: qdisc spin lock

2016-04-15 Thread Michael Ma
2016-04-08 7:19 GMT-07:00 Eric Dumazet : > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: >> I didn't really know that multiple qdiscs can be isolated using MQ so >> that each txq can be associated with a particular qdisc. Also we don't >> really have multiple

Re: qdisc spin lock

2016-04-13 Thread Michael Ma
2016-03-31 20:44 GMT-07:00 John Fastabend : > On 16-03-31 04:48 PM, Michael Ma wrote: >> I didn't really know that multiple qdiscs can be isolated using MQ so >> that each txq can be associated with a particular qdisc. Also we don't >> really have multiple interfaces... >

Re: qdisc spin lock

2016-04-08 Thread Eric Dumazet
On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: > I didn't really know that multiple qdiscs can be isolated using MQ so > that each txq can be associated with a particular qdisc. Also we don't > really have multiple interfaces... > > With this MQ solution we'll still need to assign transmit

Re: qdisc spin lock

2016-04-01 Thread Michael Ma
2016-03-31 19:19 GMT-07:00 David Miller : > From: Michael Ma > Date: Thu, 31 Mar 2016 16:48:43 -0700 > >> I didn't really know that multiple qdiscs can be isolated using MQ so > ... > > Please stop top-posting. Sorry that I wasn't aware of this...

Re: qdisc spin lock

2016-03-31 Thread John Fastabend
On 16-03-31 04:48 PM, Michael Ma wrote: > I didn't really know that multiple qdiscs can be isolated using MQ so > that each txq can be associated with a particular qdisc. Also we don't > really have multiple interfaces... MQ will assign a default qdisc to each txq and the default qdisc can be

Re: qdisc spin lock

2016-03-31 Thread David Miller
From: Michael Ma Date: Thu, 31 Mar 2016 16:48:43 -0700 > I didn't really know that multiple qdiscs can be isolated using MQ so ... Please stop top-posting.

Re: qdisc spin lock

2016-03-31 Thread Michael Ma
I didn't really know that multiple qdiscs can be isolated using MQ so that each txq can be associated with a particular qdisc. Also we don't really have multiple interfaces... With this MQ solution we'll still need to assign transmit queues to different classes by doing some math on the bandwidth

Re: qdisc spin lock

2016-03-31 Thread Michael Ma
Thanks for the suggestion - I'll try the MQ solution out. It seems to be able to solve the problem well with the assumption that bandwidth can be statically partitioned. 2016-03-31 12:18 GMT-07:00 Jesper Dangaard Brouer : > > On Wed, 30 Mar 2016 00:20:03 -0700 Michael Ma

Re: qdisc spin lock

2016-03-31 Thread Cong Wang
On Wed, Mar 30, 2016 at 12:20 AM, Michael Ma wrote: > As far as I understand the design of TC is to simplify locking schema > and minimize the work in __qdisc_run so that throughput won’t be > affected, especially with large packets. However if the scenario is > that multiple

Re: qdisc spin lock

2016-03-31 Thread Jesper Dangaard Brouer
On Wed, 30 Mar 2016 00:20:03 -0700 Michael Ma wrote: > I know this might be an old topic so bare with me – what we are facing > is that applications are sending small packets using hundreds of > threads so the contention on spin lock in __dev_xmit_skb increases the > latency