netdev - Re: netem and hierarchical ingress traffic shaping

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]

Date:	Fri, 23 Dec 2011 20:21:23 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Dave Taht <dave.taht@...il.com>,
	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>,
	netdev@...r.kernel.org
Subject: Re: netem and hierarchical ingress traffic shaping

Le vendredi 23 décembre 2011 à 11:07 -0800, Stephen Hemminger a écrit :

> skb_cb is the dumping ground of the networking layer.
> The assumption was that the qdisc could use the skb_cb
> for it's own scratchpad. Netem is using it for tagging
> packets in the queue. 
> 
> So basically, netem, choke, and sfb are incompatible with
> each other. This is not that bad, why not add a flag to qdisc
> ops to indicate which qdisc are using cb and block user from
> trying to do something bogus.

This is not how I planned to solve the problem.

I think we need an internal tfifo for netem use.

Then be able to add another qdisc on top of netem.


tfifo as a first stage, hardcoded (only limit is tunable)
[ optional 2nd stage, any qdisc ]

netem_queue()
{
	queue packet to tfifo
	(eventually at head, of reordering)
}

netem_dequeue()
{
	if (other_qdisc) {
		for_each_packet_from_tfifo_time_ready() {
			other_qdisc->enqueue(skb);
		}
		try_to_dequeue_one_packet_from(other_qdisc);
	} else {
		dequeue_one_packet_from_tfifo_time_ready();
	}
}


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