netdev - Re: [PATCH] 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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Dec 2011 09:38:22 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	rshriram@...ubc.ca
Cc:	netdev@...r.kernel.org, Brendan Cully <brendan@...ubc.ca>
Subject: Re: [PATCH] net/sched: sch_plug - Queue traffic until an explicit
 release command

Sorry - I didnt see your earlier CC. Cyberus.ca is probably the
worst service provider in Canada (maybe the world; i am sure there
are better ISPs in the middle of an ocean somewhere, deep underwater
probably).

On Mon, 2011-12-19 at 13:22 -0800, rshriram@...ubc.ca wrote:
> This qdisc can be used to implement output buffering, an essential
> functionality required for consistent recovery in checkpoint based
> fault tolerance systems. 

I am trying to figure where this qdisc runs - is it in the hypervisor?

> The qdisc supports two operations - plug and
> unplug. When the qdisc receives a plug command via netlink request,
> packets arriving henceforth are buffered until a corresponding unplug
> command is received.

Ok, so plug indicates "start of checkpoint" and unplug the end.
Seems all you want is at a certain point to throttle the qdisc and
later on unplug/unthrottle, correct?
Sounds to me like a generic problem that applies to all qdiscs?

> Its intention is to support speculative execution by allowing generated
> network traffic to be rolled back. It is used to provide network
> protection for domUs in the Remus high availability project, available as
> part of Xen. This module is generic enough to be used by any other
> system that wishes to add speculative execution and output buffering to
> its applications.

Should get a nice demo effect of showing a simple ping working with
zero drops, but: what is the effect of not even having this qdisc?
If you just switch the qdisc to a sleeping state from user space, all
packets arriving at that qdisc will be dropped during the checkpoint
phase (and the kernel code will be tiny or none). 
If you do nothing some packets will be buffered and a watchdog 
will recover them when conditions become right.
So does this qdisc add anything different?

[Note: In your case when arriving packets find the queue filled up 
you will drop lotsa packets - depending on traffic patterns; so
not much different than above]

> +
> +#define FIFO_BUF    (10*1024*1024)

Aha.
Technically - use tc to do this. Conceptually:
This is probably what makes you look good in a demo if you have one; 
huge freaking buffer. If you are doing a simple ping (or a simple
interactive session like ssh) and you can failover in 5 minutes you
still wont be able to fill that buffer!

Look at the other feedback given to you (Stephen and Dave responded).

If a qdisc is needed, should it not be a classful qdisc?

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