netdev - Re: [PATCH V2] net/sched: sch_plug - Queue traffic until an explicit release command

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] [day] [month] [year] [list]

Message-Id: <64B068C1-DE39-4487-9829-31B6B9055B56@cs.ubc.ca>
Date:	Tue, 31 Jan 2012 08:20:07 -0800
From:	Shriram Rajagopalan <rshriram@...ubc.ca>
To:	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	"\" \" <netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
	BrendanCully <brendan@...ubc.ca>
Subject: Re: [PATCH V2] net/sched: sch_plug - Queue traffic until an explicit release command

On 2012-01-31, at 7:25 AM, Hagen Paul Pfeifer <hagen@...u.net> wrote:

> 
> On Mon, 30 Jan 2012 08:47:45 -0800, Shriram Rajagopalan wrote:
> 
>> Could you elaborate a little on the packet-based-unplug ?
>> 
>> I got your earlier comment on "indefinite unplug" until an explicit
>> plug is received. Is that what you mean by packet-based-unplug ?
> 
> Sure, imagine a multihop MANET network. Sometimes we have high-priority
> crosstraffic in the next hop (router). Due to OLSR traffic information we
> know in advance that the next hop is not in the ability to forward our low
> priority packets. With this knowledge we can stop (unplug) local generated
> and forwarded traffic and if the next hop has enough free bandwidth we can
> restart (plug) sending already enqueued packets.
> 

I am assuming you mean stop(plug) and restart (unplug). But I get the idea.
Indefinite buffering (subject to qlimit) and release.

Will work on it. Thanks for the cool example :).

Shriram
> So for us a really simple plug/unplug mechanism is superior. Maybe a
> head-drop FIFO based policy for forwarded traffic but I can provide a patch
> on top of your patch to implement a head-drop policy.
> 
> Hagen
> 
--
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