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