Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Apr 2007 18:49:30 +1000
From:      Alan Garfield <alan@fromorbit.com>
To:        Yar Tikhiy <yar@comp.chem.msu.su>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: RFI: Ethernet driver ported from Linux
Message-ID:  <1176972570.4177.1.camel@hiro.auspc.com.au>
In-Reply-To: <20070419075604.GB60301@comp.chem.msu.su>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> 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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1176972570.4177.1.camel>