Date: Thu, 19 Apr 2007 12:34:16 -0700 From: Julian Elischer <julian@elischer.org> To: Alan Garfield <alan@fromorbit.com> Cc: Yar Tikhiy <yar@comp.chem.msu.su>, freebsd-hackers@freebsd.org Subject: Re: RFI: Ethernet driver ported from Linux Message-ID: <4627C438.8000304@elischer.org> In-Reply-To: <1176972570.4177.1.camel@hiro.auspc.com.au> References: <1176096815.4064.6.camel@hiro.auspc.com.au> <20070409.222300.-1350498722.imp@bsdimp.com> <20070417171622.GB95814@comp.chem.msu.su> <1176858032.4426.3.camel@hiro.auspc.com.au> <20070418074455.GD36635@comp.chem.msu.su> <1176948890.4175.50.camel@hiro.auspc.com.au> <20070419075604.GB60301@comp.chem.msu.su> <1176972570.4177.1.camel@hiro.auspc.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Garfield wrote: > On Thu, 2007-04-19 at 11:56 +0400, Yar Tikhiy wrote: >> >>> Apart from using fake MAC addresses, I don't think so. >> I don't understand the concept of a fake MAC address, sorry. >> The classic Ethernet is a broadcast medium by design, so a very >> primitive NIC can just receive all traffic and let the driver or >> network stack decide if the host wants a particular frame. On >> output, the network stack can usually put any source MAC address >> into the frame -- it's true for the most of Ethernet network >> interfaces. So MAC addresses are always "fake" in a sense, as >> neither the hardware nor the medium design enforces them. > > You're right. I don't fully understand quite what's happening behind the > scene it would seem. It sounds like this should be a "point-to-point" interface, and not an Ethernet interface.. If I understand what you are saying there is only ever communications between 2 entities. What is on the other side of this connection? > >> If I understand your case right, the two processors, CPU and SP, >> share a hardware buffer, in which they can put some data for the >> other side, e.g., an Ethernet frame, and then prod the other side >> with an interrupt. That fits the Ethernet model ideally, so there >> should be no need for hacks unless the other side, the SP running >> a special Linux, takes the whole thing wrong. > > Again, you're correct. The Linux driver does have a certain 'quality' to > it, but otherwise it should work as you've said. > > Alan. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4627C438.8000304>