netdev - Re: qdisc spin lock

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: <CAAmHdhx-nW_eAuTy_0z9j6fc-3RebyntMk9yFyAfndmkgSbtVA@mail.gmail.com>
Date:	Wed, 13 Apr 2016 11:23:23 -0700
From:	Michael Ma <make0818@...il.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Cong Wang <xiyou.wangcong@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: qdisc spin lock

2016-03-31 20:44 GMT-07:00 John Fastabend <john.fastabend@...il.com>:
> 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 changed to htb or any other qdisc of your choice.
>
>>
>> With this MQ solution we'll still need to assign transmit queues to
>> different classes by doing some math on the bandwidth limit if I
>> understand correctly, which seems to be less convenient compared with
>> a solution purely within HTB.
>>
>
> Agreed.
>
>> I assume that with this solution I can still share qdisc among
>> multiple transmit queues - please let me know if this is not the case.
>
> Nope sorry doesn't work that way unless you employ some sort of stacked
> netdevice strategy which does start to get a bit complex. The basic hint
> would be to stack some type of virtual netdev on top of a device and
> run the htb qdisc there. Push traffic onto the netdev depending on the
> class it belongs to. Its ugly yes.

Thanks for the input - is it possible to implement a MQ to allow one
qdisc to be associated with multiple TXQ belonging to one inner class?
Does that require any additional synchronization in qdisc routines? I
think it shouldn't because the common use of TC already associates one
qdisc with all the TXQ. This would simplify the way that qdisc is
crafted since it doesn't need to be created for each queue.

Also is it possible to allow multiple qdiscs to be associated with one
TXQ? I can see one issue with this - the TC interface for MQ today
doesn't allow one TXQ to be associated with multiple classes, but this
seems to be a restriction only from the tc command interface
perspective. MQ anyway only establishes a connection between TXQ and
qdisc so theoretically we can associate one TXQ to multiple
classes/qdiscs and use priority/classid of the packet to do the
pre-selection of qdisc. Again, I might have missed some potential
synchronization issue when this actually happens because today TXQ is
not shared by multiple qdiscs in any case.

>
> Noting all that I posted an RFC patch some time back to allow writing
> qdiscs that do not require taking the lock. I'll try to respin these
> and submit them when net-next opens again. The next logical step is to
> write a "better" HTB probably using a shared counter and dropping the
> requirement that it be exact.
>
> Sorry I didn't get a chance to look at the paper in your post so not
> sure if they suggest something similar or not.
>
> Thanks,
> John
>
>>
>> 2016-03-31 15:16 GMT-07:00 Cong Wang <xiyou.wangcong@...il.com>:
>>> On Wed, Mar 30, 2016 at 12:20 AM, Michael Ma <make0818@...il.com> 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 classes in the queueing discipline only have the shaping
>>>> limit, there isn’t really a necessary correlation between different
>>>> classes. The only synchronization point should be when the packet is
>>>> dequeued from the qdisc queue and enqueued to the transmit queue of
>>>> the device. My question is – is it worth investing on avoiding the
>>>> locking contention by partitioning the queue/lock so that this
>>>> scenario is addressed with relatively smaller latency?
>>>
>>> If your HTB classes don't share bandwidth, why do you still make them
>>> under the same hierarchy? IOW, you can just isolate them either with some
>>> other qdisc or just separated interfaces.
>