From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Wed, 16 Jun 2010 20:10:49 EDT." References: <20100616234310.082625B76@mail.bitblocks.com> From: Bakul Shah Date: Wed, 16 Jun 2010 19:02:30 -0700 Message-Id: <20100617020231.0F62C5B76@mail.bitblocks.com> Subject: Re: [9fans] Inducing artificial latency Topicbox-Message-UUID: 3508b5ba-ead6-11e9-9d60-3106f5b1d025 On Wed, 16 Jun 2010 20:10:49 EDT erik quanstrom 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.