netdev - Re: [PATCH net-next v4] rps: selective flow shedding during softnet overflow

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: <517734A2.9060609@mojatatu.com>
Date:	Tue, 23 Apr 2013 21:25:54 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Stephen Hemminger <stephen@...workplumber.org>,
	Willem de Bruijn <willemb@...gle.com>,
	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH net-next v4] rps: selective flow shedding during softnet
 overflow

On 13-04-23 08:09 PM, Eric Dumazet wrote:

> qdisc code has a hardcoded dev_hard_start_xmit() call, thats why ifb
> hack is used. Not mentioning device flow control.
>
> It might be possible to use a q->xmit() method instead, so that it can
> be used on ingress without ifb.
>

If i understood correctly what you are trying to achieve:
I dont think one qdisc per rx queue/ring will work well in
presence of qdisc since the qdisc is attached per netdev.
i.e when packets are fanned out across cpu backlogs, as long
as they came in via same netdev queue, they are going to share
the same lock with all other cpus such packets have been fanned out to
the moment you attach an ingress qdisc to that netdev ring/queue.

One unorthodox approach is to have a qdisc per backlog queue
since the backlog is per cpu; given it is abstracted as a netdev,
it becomes a natural fit (sans the fact backlog queue is
unidirectional).

cheers,
jamal

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