Re: [9fans] Inducing artificial latency

[erik quanstrom <quanstro@quanstro.net>]

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

you don't need to dedicate a port.  just open protocol -1.

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

my application requires doing this for (multiple)
10gbe at wire speed.

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

i'm sure it's not perfect.  but there are a lot of system
dependencies in there.  i don't think it's worth factoring
more stuff out, but i'd love someone to show that i'm wrong.

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

if you look carefully, none of this is actually used;
there are vlan tags mentioned in the ring entries, but
they are ignored.  as an example, take the 82598.

78: 	Vfta		= 0x0a000/4,	/* vlan filter table array. */
80: 	Vlnctrl		= 0x05088/4,	/* vlan control */
86: 	Imirvp		= 0x05ac0/4,	/* immediate irq vlan priority */
258: 	ushort	vlan;
279: 	ushort	vlan;

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

if you're doing the delay stuff at the ether level, i fail to see
what ip stuff (nat) has to do with it.

- erik