Re: [9fans] Inducing artificial latency

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Wed, 16 Jun 2010 20:10:49 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > You'd need some plumbing in devether to demultiplex incoming
> > packets addressed to this device (assuming it has its own MAC
> > address).
>
> i don't think you would.  if you're using the latency device as your
> ethernet device, no muxing is required.

Yes, if you dedicate a port. A reasonable tradeoff in some cases.

> > Something like a tap device would allow you to simulate high
> > latency link, a level-2 bridge or whatever in usercode.
>
> this is difficult to do in user space for two reasons
> 1.  the difficulty of getting precision timing.
> 2.  copies into/out of the kernel.

I don't see what "difficulty" has to do with your two points.
The goal here would be flexibility more than performance.
Even so, modern machines are fast enough so lower performance
is not a big issue for many uses. See for instance vde (under
linux and FreeBSD). These days in qemu I can get very decent
network speeds (network installs of freebsd under qemu
operate faster than they did on native machines of a few
years back).

> > [BTW, is there a strong reason why devether.c is in 9/pc/ and
> >  not 9/port/?  vlan code can be factored out from various
> >  ether*.c to a similar portable file (if not devether.c)]
>
> actually, most of the code has been factored out, but one step
> better than you imagine.  most of the code is in ../port/netif.c
> which should be a good start on any type of network interface.

Good!

> what remains is code littered with system dependencies.  it's
> worthwhile comparing pc/devether.c with kw/devether.c

I did.  A lot of the code is the same. More can be factored
out (as the diff shows some fixes appear in one and not the
other).

> by the way, there is no vlan code, as far as i know, which
> is absolutely fine by me.

grep -i vlan /sys/src/9/pc/ether*

> > A user level simulator will make it easy to add random drops,
> > reordering, filtering, NAT, etc.
>
> what do you mean by mac-level natting?  something like
> hp vc?  seems way too extravagant for a simple packet muncher.

I meant IP natting (but doing it in usercode). The point was
something like tap would allow you to munge packets however
you wished and stuff them back into kernel pkt queues.

> by the way,  if you keep the packets in the order they should
> be released from the delay queue, reordering is automatic.

Reorder in this (testing) context is to purposely get packets
out of order.

Plan9 is a very good platform for experimenting and for real
uses.  Even if such experiments fail or are done in areas we
might avoid (such as vlans), it is all good!  If drivers can
be written in user mode, that makes plan9 even more flexible.
Of course, what gets accepted back in standard plan9 code
base is a different matter.