On 1998-10-27 at 08:09:47, Mark Spencer wrote:
[I wrote about bridging artifacts]
> > just an implementation detail. The current bridge is just doing the
> > work "behind the back" of the networking code, so a packet is either
> But in an important sense, that *is* the proper behavior of a bridge. I
> would certainly want a few second opinions before I started trying to get
> the bridge code to look into the headers and such. But still, you're
Oh, I didn't mean it look into higher level headers. It's simply
unacceptable currently that the "other" interface is completely
invisible since packets to it are not forwarded, and they are not
recognized as "local" on the closer interface. (At least that's what I
think the problem is.] By using a virtual bridge interface would simply
allow more convenient, rational management, and also bridging between
the physical interfaces exactly like now. [I.e. packets either are
forwarded between the interfaces, or passed upwards. Currently the last
operation is not correctly aligned with the rest of the internal
networking architecture.]
> missing the point of our project. NADS shouldn't be tied to the bridging
> code at all. If you have high peer-to-peer traffic in addition to the
Of course. Bridging can also easily bring a server down to its knees,
since all related interfaces must be in promiscuous mode, which is
really not acceptable, except maybe the case when there is *very* light
peer to peer traffic, even between nodes on the same physical network.
I just tried to make sure you don't want to hack around the current
misbehavior of the bridging code. And of course, in a few, a bit even
more special cases NADS aims to be much more efficient. But this
brought up something in my mind which is really NADS related, will send
in a separate message.
> client-server traffic, then you really ought to have an external bridge or
> switch or whatever (as is diagrammed on our web site). NADS should work
> independently of the bridging code, not as an extention or piece of it.
> The hope is only that it will co-operate with it to allow the server to be
> a server and bridge if that happens to be the way you want to run it.
I'll be curious what this should take from the current code; I just
started looking again at the bridging code, maybe I can help with this
part.
> > As far as I can see, the fast routing code, as well as the hypothetical
> > fast bridging as an extension, is only being able to speed up operation
> > by overlapping the computing of destination path with receiving the rest
[...]
> I thought that it bypassed the CPU for sending most of the payload by
> doing card->card transfers. Do those work in a store-and-forward sense?
Umm, it seems I misunderstood something; by looking again, it seems to
really do what I claimed it can't, namely it tries to decide quickly
where to forward the packet and start the transmit while still
receiving. However to me it looks a bit kludgy; very brilliant, but I
can't believe it works.. :)
But it's time to move to the NADS list, I hope every interested party
will find it too.
-- Janos - Don't worry, my address is real. I'm just bored of spam.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/