2017-11-13 20:53 GMT-08:00 Tom Herbert :
> On Mon, Nov 13, 2017 at 7:45 PM, John Fastabend
> wrote:
>> On 11/13/2017 06:18 PM, Michael Ma wrote:
>>> 2017-11-13 16:13 GMT-08:00 Alexander Duyck :
>>>> On Mon, Nov 13, 2017 at 3:08 PM, Eric Dumazet
>>>
2017-11-13 19:45 GMT-08:00 John Fastabend :
> On 11/13/2017 06:18 PM, Michael Ma wrote:
>> 2017-11-13 16:13 GMT-08:00 Alexander Duyck :
>>> On Mon, Nov 13, 2017 at 3:08 PM, Eric Dumazet
>>> wrote:
>>>> On Mon, 2017-11-13 at 14:47 -0800, Alexander Duyck wro
2017-11-13 18:18 GMT-08:00 Michael Ma :
> 2017-11-13 16:13 GMT-08:00 Alexander Duyck :
>> On Mon, Nov 13, 2017 at 3:08 PM, Eric Dumazet wrote:
>>> On Mon, 2017-11-13 at 14:47 -0800, Alexander Duyck wrote:
>>>> On Mon, Nov 13, 2017 at 10:17 AM, Michael Ma wrote:
>
2017-11-13 16:13 GMT-08:00 Alexander Duyck :
> On Mon, Nov 13, 2017 at 3:08 PM, Eric Dumazet wrote:
>> On Mon, 2017-11-13 at 14:47 -0800, Alexander Duyck wrote:
>>> On Mon, Nov 13, 2017 at 10:17 AM, Michael Ma wrote:
>>> > 2017-11-12 16:14 GMT-08:00 Stephen Hemminge
2017-11-13 18:05 GMT-08:00 Michael Ma :
> 2017-11-13 15:08 GMT-08:00 Eric Dumazet :
>> On Mon, 2017-11-13 at 14:47 -0800, Alexander Duyck wrote:
>>> On Mon, Nov 13, 2017 at 10:17 AM, Michael Ma wrote:
>>> > 2017-11-12 16:14 GMT-08:00 Stephen Hemminger :
>>>
2017-11-13 15:08 GMT-08:00 Eric Dumazet :
> On Mon, 2017-11-13 at 14:47 -0800, Alexander Duyck wrote:
>> On Mon, Nov 13, 2017 at 10:17 AM, Michael Ma wrote:
>> > 2017-11-12 16:14 GMT-08:00 Stephen Hemminger :
>> >> On Sun, 12 Nov 2017 13:43:13 -0800
>> &g
2017-11-13 14:47 GMT-08:00 Alexander Duyck :
> On Mon, Nov 13, 2017 at 10:17 AM, Michael Ma wrote:
>> 2017-11-12 16:14 GMT-08:00 Stephen Hemminger :
>>> On Sun, 12 Nov 2017 13:43:13 -0800
>>> Michael Ma wrote:
>>>
>>>> Any comments? We plan
2017-11-12 16:14 GMT-08:00 Stephen Hemminger :
> On Sun, 12 Nov 2017 13:43:13 -0800
> Michael Ma wrote:
>
>> Any comments? We plan to implement this as a qdisc and appreciate any early
>> feedback.
>>
>> Thanks,
>> Michael
>>
>&
Any comments? We plan to implement this as a qdisc and appreciate any early
feedback.
Thanks,
Michael
> On Nov 9, 2017, at 5:20 PM, Michael Ma wrote:
>
> Currently txq/qdisc selection is based on flow hash so packets from
> the same flow will follow the order when they enter qdis
Currently txq/qdisc selection is based on flow hash so packets from
the same flow will follow the order when they enter qdisc/txq, which
avoids out-of-order problem.
To improve the concurrency of QoS algorithm we plan to have multiple
per-cpu queues for a single TC class and do busy polling from a
Hi -
As I mentioned in a previous thread, we're implementing a qdisc
similar to mqprio which can associate multiple txqs to one qdisc, so
that we can work around the root qdisc bottleneck. I think this should
be in general fine since without MQ, root qdisc is associated with
multiple txqs anyway.
2017-04-18 21:46 GMT-07:00 Michael Ma :
> 2017-04-18 16:12 GMT-07:00 Cong Wang :
>> On Mon, Apr 17, 2017 at 5:39 PM, Michael Ma wrote:
>>> Hi -
>>>
>>> We've implemented a "glue" qdisc similar to mqprio which can associate
>>> one qdis
2017-04-18 16:12 GMT-07:00 Cong Wang :
> On Mon, Apr 17, 2017 at 5:39 PM, Michael Ma wrote:
>> Hi -
>>
>> We've implemented a "glue" qdisc similar to mqprio which can associate
>> one qdisc to multiple txqs as the root qdisc. Reference count of the
>
Hi -
We've implemented a "glue" qdisc similar to mqprio which can associate
one qdisc to multiple txqs as the root qdisc. Reference count of the
child qdiscs have been adjusted properly in this case so that it
represents the number of txqs it has been attached to. However when
sending packets we s
2016-11-01 4:38 GMT-07:00 Jamal Hadi Salim :
> On 16-10-31 02:10 PM, David Miller wrote:
>>
>> From: Michael Ma
>> Date: Mon, 31 Oct 2016 11:02:28 -0700
>>
>>> 2016-10-28 14:52 GMT-07:00 Michael Ma :
>>>>
>>>> 2016-10-28 14:48 GMT-07:00
2016-10-31 11:02 GMT-07:00 Michael Ma :
> 2016-10-28 14:52 GMT-07:00 Michael Ma :
>> 2016-10-28 14:48 GMT-07:00 Stephen Hemminger :
>>> On Fri, 28 Oct 2016 14:45:07 -0700
>>> Michael Ma wrote:
>>>
>>>> 2016-10-28 14:38 GMT-07:00 Stephen Hemmi
2016-10-28 14:52 GMT-07:00 Michael Ma :
> 2016-10-28 14:48 GMT-07:00 Stephen Hemminger :
>> On Fri, 28 Oct 2016 14:45:07 -0700
>> Michael Ma wrote:
>>
>>> 2016-10-28 14:38 GMT-07:00 Stephen Hemminger :
>>> > On Fri, 28 Oct 2016 14:36:27 -070
Hi -
Currently IFB uses tasklet to process tx/rx on the interface that
forwarded the packet to IFB. My understanding on why we're doing this
is that since dev_queue_xmit() can be invoked in interrupt, we want to
defer the processing of original tx/rx in case ifb_xmit() is called
from interrupt.
H
2016-09-16 15:00 GMT-07:00 Michael Ma :
> 2016-09-16 12:53 GMT-07:00 Eric Dumazet :
>> On Fri, 2016-09-16 at 10:57 -0700, Michael Ma wrote:
>>
>>> This is actually the problem - if flows from different RX queues are
>>> switched to the same RX queue in IFB
2016-09-16 12:53 GMT-07:00 Eric Dumazet :
> On Fri, 2016-09-16 at 10:57 -0700, Michael Ma wrote:
>
>> This is actually the problem - if flows from different RX queues are
>> switched to the same RX queue in IFB, they'll use different processor
>> context with the sa
2016-09-15 17:51 GMT-07:00 Michael Ma :
> 2016-09-14 10:46 GMT-07:00 Michael Ma :
>> 2016-09-13 22:22 GMT-07:00 Eric Dumazet :
>>> On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote:
>>>
>>>> I don't intend to install multiple qdisc - the only reason th
2016-09-14 10:46 GMT-07:00 Michael Ma :
> 2016-09-13 22:22 GMT-07:00 Eric Dumazet :
>> On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote:
>>
>>> I don't intend to install multiple qdisc - the only reason that I'm
>>> doing this now is to leverage MQ
2016-09-13 22:22 GMT-07:00 Eric Dumazet :
> On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote:
>
>> I don't intend to install multiple qdisc - the only reason that I'm
>> doing this now is to leverage MQ to workaround the lock contention,
>> and based on the p
2016-09-13 22:13 GMT-07:00 Michael Ma :
> 2016-09-13 18:18 GMT-07:00 Eric Dumazet :
>> On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote:
>>
>>> If I understand correctly this is still to associate a qdisc with each
>>> ifb TXQ. How should I do this if I want to
2016-09-13 18:18 GMT-07:00 Eric Dumazet :
> On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote:
>
>> If I understand correctly this is still to associate a qdisc with each
>> ifb TXQ. How should I do this if I want to use HTB? I guess I'll need
>> to divide the band
2016-09-13 17:09 GMT-07:00 Eric Dumazet :
> On Tue, 2016-09-13 at 16:30 -0700, Michael Ma wrote:
>
>> The RX queue number I found from "ls /sys/class/net/eth0/queues" is
>> 64. (is this the correct way of identifying the queue number on NIC?)
>> I setup ifb with
Hi -
We currently use mqprio on ifb to work around the qdisc root lock
contention on the receiver side. The problem that we found was that
queue_mapping is already set when redirecting from ingress qdisc to
ifb (based on RX selection, I guess?) so the TX queue selection is not
based on priority.
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, Michael Ma wrote:
>>> &g
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 :
>> >> &g
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 be isolated
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 multipl
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 be isolated
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 multipl
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 int
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...
:
> 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
>
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 wrote:
>
Hi -
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 of dev_queue_xmit significantly. We’re building a network QoS
solution to avoi
38 matches
Mail list logo
