From: "Steve Schmidtke" <steve_schmidtke@hotmail.com>
To: mcr@sandelman.ottawa.on.ca, kraxel@bytesex.org
Cc: blaisorblade_spam@yahoo.it, uml@uxu.ch, jdike@addtoit.com,
user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: What to do with uml_switch?
Date: Wed, 08 Dec 2004 19:36:25 +0000 [thread overview]
Message-ID: <BAY24-F39F020DFE0870A8FDC91DC83B60@phx.gbl> (raw)
In-Reply-To: <5810.1102524702@marajade.sandelman.ottawa.on.ca>
Michael Richardson wrote:
> Gerd> Hmm, I don't think it is a good idea to put that kind of
> Gerd> testing code into the switch daemon. I'd make the switch
> Gerd> daemon behave as close as possible to a real switch, then use
> Gerd> the normal tools you use for real networks as well. I think
> Gerd> uml_switch should just support a monitor port which will see
>
> Not practical, not reliable.
Why not reliable? A monitor port is a diagnostic tool, and there is no
reason you couldn't run it in a sychronous mode with the switch, i.e. the
switch is paused as the monitor inspects an IO event (an input packet) and
either allows it to proceed or be modified in some way (replaced, dropped,
etc).
I will agree that it wouldn't be fit for all purposes. There is obviously a
delay as a packet must be written to the monitor app for inspection, a
context switch to the monitor, an ACK written from the monitor, a context
switch back, and the ACK processed, before a packet can be disposed of.
Does that make a monitor port impractical? I don't think so. The real
world delay I've been seeing so far on my test monitor doing just that for
ping round trip times is less than a millisecond. I havn't tried larger
packets yet.
On the other hand, once the monitor has ACK'd a packet, the switch and
monitor app are free to continue processing independently, possibly reducing
overall delay times.
> Often, not even possible if you wish to play packets that Linux simply
>can not easily produce.
There is no reason you would need to use Linux as your packet source:
cat tcpdump.pcap | switch_mon_tool --socket /tmp/uml.mon --delay 100ms
is the type of functionality I'm shooting for (above example not to be taken
literally).
Steve Schmidtke
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2004-12-08 19:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 3:52 [uml-devel] What to do with uml_switch? Blaisorblade
2004-12-05 3:42 ` [uml-devel] " Michael Richardson
2004-12-06 19:25 ` Gerd Knorr
2004-12-07 16:21 ` Steve Schmidtke
2004-12-08 16:51 ` Michael Richardson
2004-12-08 19:33 ` Gerd Knorr
2004-12-09 3:22 ` Michael Richardson
2004-12-08 19:36 ` Steve Schmidtke [this message]
2004-12-08 21:37 ` Michael Richardson
2004-12-09 0:28 ` Steve Schmidtke
2004-12-09 0:53 ` Michael Richardson
2004-12-05 20:00 ` [uml-devel] " Steve Schmidtke
2004-12-06 18:30 ` [uml-devel] " Gerd Knorr
2004-12-06 19:35 ` [uml-devel] " Blaisorblade
2004-12-08 20:24 ` [uml-devel] " Felix Müri
-- strict thread matches above, loose matches on Subject: below --
2004-12-05 20:20 [uml-devel] " Steve Schmidtke
2004-12-06 1:23 ` mcr
2004-12-07 16:06 ` Steve Schmidtke
2004-12-08 17:11 ` Michael Richardson
2004-12-08 19:49 ` Steve Schmidtke
2004-12-08 21:41 ` Michael Richardson
2004-12-14 0:36 ` Werner Almesberger
2004-12-10 18:36 ` Blaisorblade
2004-12-12 0:11 ` Michael Richardson
2004-12-12 19:11 ` Steve Schmidtke
2004-12-12 20:50 ` Michael Richardson
2004-12-16 18:20 ` Blaisorblade
2004-12-06 20:16 ` Blaisorblade
2004-12-08 16:42 ` Michael Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BAY24-F39F020DFE0870A8FDC91DC83B60@phx.gbl \
--to=steve_schmidtke@hotmail.com \
--cc=blaisorblade_spam@yahoo.it \
--cc=jdike@addtoit.com \
--cc=kraxel@bytesex.org \
--cc=mcr@sandelman.ottawa.on.ca \
--cc=uml@uxu.ch \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox