netdev - Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

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: <5f2db9d90808222335p223f1577l41841fb37490d85a@mail.gmail.com>
Date:	Fri, 22 Aug 2008 23:35:24 -0700
From:	"Alexander Duyck" <alexander.duyck@...il.com>
To:	"Herbert Xu" <herbert@...dor.apana.org.au>
Cc:	davem@...emloft.net, jarkao2@...il.com, hadi@...erus.ca,
	jeffrey.t.kirsher@...el.com, jeff@...zik.org,
	netdev@...r.kernel.org, alexander.h.duyck@...el.com
Subject: Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

On Fri, Aug 22, 2008 at 10:12 PM, Herbert Xu
<herbert@...dor.apana.org.au> wrote:
> Alexander Duyck <alexander.duyck@...il.com> wrote:
>>
>> That issue led me to the thought of creating a redirect action that
>> would take the packet from one qdisc to the correct qdisc for the
>> transmit queue.  That setup has two issues.  First, all traffic would
>> need to go to one queue by default to avoid a possible deadlock
>> condition in the event that two queues try to enqueue packets on one
>> another at the same time.  That combined with the fact that one packet
>
> That looks like a problem but it isn't.  When you're overriding
> the default queue selection you're breaking CPU affinity.  As such
> cache-line bouncing is clearly not a concern or you wouldn't be
> doing this (that is, you're doing this for QOS rather than CPU
> scalability).  So having everything go through a single qdisc
> shouldn't be a problem.
>
> Cheers,

It isn't the performance aspect of running everything through one
queue that I am concerned about since that is how it was working
before.  My concern is that the action could cause a dead lock if
simple_tx_hash places traffic on 2 queues and then the tc rule tried
to swap the traffic between those queues while they are each holding
their own queue locks.  The tc rule would have to receive all traffic
onto a single qdisc to prevent this, which would require setting
select_queue for the netdev to return a fixed queue.  The multiqueue
prio qdisc is flexible enough to allow all traffic to be directed to
one queue or be received on multiple queues without causing the system
to lock up which means that implementing select_queue on the device
wouldn't be mandatory.

Thanks,

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