[3343] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: Locked Network Buffers, Emerging Technologies, and Dummy modules

daemon@ATHENA.MIT.EDU (Nick Holloway)
Thu Jun 20 00:24:27 1996

To: submit-linux-dev-net@ratatosk.yggdrasil.com
From: Nick.Holloway@alfie.demon.co.uk (Nick Holloway)
Date: 	19 Jun 1996 22:09:45 +0100

dennis@etinc.com (Dennis) writes:
> Andrew Stanley-Jones <asj@cban.com> writes:
> >Dennis can't solve the problem, and he doesn't think it's his driver. He 
> >beleives it's something to do with the dummy modules and how they 
> >operate.
> 
> I didnt say that. I said that we cant duplicate the problem (yet), and getting
> pointers on what possible interactions there are with the dummy module
> present would be helpful.

Since the dummy devices are just there to exist, so that IP addresses
can be recognised as local, there shouldn't be an interaction.

One way to really check that the dummy devices are not being passed any
packets is to change the '#undef DUMMY_STATS' in dummy.c to a '#define'.
This will then report the number of packets sent to the dummy device
in /proc/net/dev (beware, this define hasn't been turned on for over
2 years -- it may not even compile).  In theory, there should be none.
If there are any packets, and they are not being discarded correctly,
then you might end up with problems (can dummy_xmit be called with NULL
dev, and non-NULL skb?).

I would think that the best way to deal with virtual domains with 2.0
would be to use the IP aliasing.

-- 
 `O O'  | Home: Nick.Holloway@alfie.demon.co.uk
// ^ \\ | Work: Nick.Holloway@parallax.co.uk  http://www.parallax.co.uk/~alfie/


home help back first fref pref prev next nref lref last post