From: Steve S. <ste...@ho...> - 2004-11-24 02:49:14
|
Hi, While I was playing around with uml_switch, I started thinking that the code is a bit messy and really could use a facelift. I decided to sit down and do some grunt work to reorganize the code a bit to help make any future modifications to the program easier and more straightforward. Submitted for your inspection, testing, and hopeful addition to uml_router (from uml_utilites-20040406) are the following patches: Patch 1 fixes some minor bugs I noticed while making changes. It probably should be applied whether or not any of my more ambitious patches are used. Oh, and there's a stray core file for some reason in the directory that should be deleted... ;) Patch 2 adds files that are the basis of a simple IO event dispatcher. All IO processing can now be handled by a simple callback mechanisim. Patch 3 shows how to use the IO API added in patch 2 by adding a replacement stdin driver. It is over-engineered, but it is meant as an example template for writing other fd drivers. Patch 4 switches everything to the new API. I should note that these intermediate patches have not been tested to work, they just show how I got from here to there. Patch 5 adds glue and misc stuff that would be useful if one wanted to be more modular and break all the driver code out of the main file. Patch 6 (surprise) finally moves driver functions to their respective files. Not all is pretty (sockunix.c), but at least the code has now been coralled into functional groups. There is still a bit of an ifdef hell in uml_switch.c that needs work. It should be pretty straightforward to add a registration API to hide the gory details of hooking drivers into the system. If there's interest in my changes so far, I'll code up some driver registration stuff. It would be useful for my own work anyways. Enjoy! Steve Schmidtke |
From: Gerd K. <kr...@by...> - 2004-11-24 10:20:18
|
"Steve Schmidtke" <ste...@ho...> writes: > Hi, > > While I was playing around with uml_switch, I started thinking that > the code is a bit messy and really could use a facelift. BTW: not sure I ever mentioned it here, but some time ago I basically rewrote the switch daemon as well for several reasons. Main reason is that debugging network problems with the original one is very hard. While browsing the code I figured that it likely is easier to largely rewrite the stuff rather than trying to fix the existing stuff. Especially the mac handling is broken by design. The code is here: http://www.suse.de/~kraxel/uml/switch.tar.gz The README is below. Enjoy, Gerd ==============================[ cut here ]============================== This is a drop-in replacement for the uml_switch daemon from the uml-utilities package. It is very loosely based on the original uml_switch daemon code. Improvements: * Prints nice help text on '-h'. * Redesigned MAC handling, it can deal with multiple MAC addresses per switch port correctly. * Has outgoing package queues per switch port. * Drives the switch ports using non-blocking I/O for both reads and writes. * Pidfile support. Drawbacks: * supports the v3 protocol only. On my maybe-TODO list: * Reintroduce hash table for MAC lookup (not sure through that this would noticable speedup the daemon as the number of mac addresses usually is small ...). * use poll() instead of select() (again this likely doesn't make a noticable difference for most users ...). Have fun, Gerd -- Gerd Knorr <kr...@by...> [SUSE Labs] |
From: Gerd K. <kr...@by...> - 2004-11-24 19:49:18
|
> > * Has outgoing package queues per switch port. > > I wanted this as well - dropping packets just because of a temporary EAGAIN > makes network traffic stumble. I'm not sure any more that this makes actually a big difference. It may help a bit on network load peaks. The (host) kernel does some buffering as well in the fifo/socket buffers, you'll get the -EAGAIN once they are full. Buffering in the switch daemon as well just makes the buffer space bigger, but at some point you have to drop packets. The TCP protocol has a clever algoritm to get as much as possible out of a link between two machines which actually *depends* on packets being dropped once you've over the limit for the link. Thus dropping packets isn't something you should try to avoid at any cost. You can't do that anyway ;) > But one thing I think I noticed is you don't expire packets if they > get stale (packet dropping seems to drop the newest packet rather than > the oldest as well), which could cause problems too. Not sure what a real switch/router does in that case. Note that the packets which are already in the kernel's fifo/socket buffer can't be expired as well ... > > * use poll() instead of select() (again this likely doesn't make a > > noticable difference for most users ...). > > Not to have completely wasted my time, the io dispatcher I wrote around > poll() should be an easy retrofit in your package as well, if you want it. > > Or, if it would be useful, I would be happy to try and integrate both > packages together. Feel free to go ahead with merging code and push it upstream. Gerd -- #define printk(args...) fprintf(stderr, ## args) |
From: <um...@ux...> - 2004-11-24 20:32:15
|
Gerd Knorr schrieb: > "Steve Schmidtke" <ste...@ho...> writes: > > >>Hi, >> >>While I was playing around with uml_switch, I started thinking that >>the code is a bit messy and really could use a facelift. > > While browsing the code I figured that it likely is easier to largely > rewrite the stuff rather than trying to fix the existing stuff. > Especially the mac handling is broken by design. > Hello, long ago I found similar issues with the uml_switch codebase. My problem was not the mac handling, but an missing feature to connect two switches together via an udp-tunnel. I have rewritten (but not redesigned) most of the code. The latest published codebase can be found here: http://www.uxu.ch/uxu/software/uml_switch2 regards Felix P.S.: My code is (since about a year) in the state of further improvement (I want an uml-switch, which can start and stop uml-guests and be controlled via a control socket), but this codebase is actually not in an releasable state (although I use it on my production machine :-) |
From: Gerd K. <kr...@by...> - 2004-11-24 21:20:08
|
> long ago I found similar issues with the uml_switch codebase. My > problem was not the mac handling, but an missing feature to > connect two switches together via an udp-tunnel. How did you actually implement that? When using lossy UDP anyway it should be almost trivial to remove the restriction to two switch deamons by using IP Multicast for the communication ... Gerd -- #define printk(args...) fprintf(stderr, ## args) |
From: Steve S. <ste...@ho...> - 2004-11-24 22:03:15
|
Felix Müri <um...@ux...> wrote: >long ago I found similar issues with the uml_switch codebase. My problem >was not >the mac handling, but an missing feature to connect two switches together >via an >udp-tunnel. Interesting. Is there a way to signal the program that a remote switch is not responding? >(I want an uml-switch, which can start and stop uml-guests and be >controlled via a >control socket) Hmmm, is that the right spot for control? I'd be concerned that a unsecured UDP port would allow someone to inject arbitrary control packets between the switches. A seperate daemon that spoke mconsole securely and could talk to uml_switch would probably make more sense and be safer. Steve Schmidtke |