Date: Wed, 17 Jun 2009 02:15:27 +0200 From: Alexey Shuvaev <shuvaev@physik.uni-wuerzburg.de> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: Bruce Simpson <bms@incunabulum.net>, freebsd-current@freebsd.org Subject: Re: CFT: fxp(4) Message-ID: <20090617001527.GB4146@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090615084850.GD78415@michelle.cdnetworks.co.kr> References: <20090615044106.GC78415@michelle.cdnetworks.co.kr> <4A36018E.2050301@incunabulum.net> <20090615084850.GD78415@michelle.cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 15, 2009 at 05:48:50PM +0900, Pyun YongHyeon wrote:
> On Mon, Jun 15, 2009 at 09:08:46AM +0100, Bruce Simpson wrote:
> > Pyun YongHyeon wrote:
> > >Please test the patch in the following URL if you have fxp(4)
> > >hardwares. The patch contains various accumulated fixes for
> > >multicast handling, bus_dma fixes, more sane initialization
> > >and enhanced lockup detection for buggy controllers.
> >
> > This is just a note to say that I *have* observed problems with
> > multicast setup in fxp(4) -- it seems to need setting up of the
> > link-layer hash filter for a group to transmit as well as receive.
> >
>
> I couldn't see this limitation in datasheet. So it could be a
> bug in stock fxp(4).
>
> > This isn't OK, NICs should be able to transmit w/o receive setup, and
> > may break normal use-cases (esp. IPv6), I posted to freebsd-net@ about
> > this over the past 12 months, but did not have time to reproduce or
> > isolate the issue. So a fix is very, very welcome. Thanks for working on
> > this.
>
> So does that patch fixed the issue? I'm not familiar with
> multicasting but I did my best to make fxp(4) work on multicasting
> environments. fxp(4) hardwares do not allow multicast hash filter
> programming when device is not in idle state. So stock fxp(4)
> used to rely on Tx completion interrupt to program multicast
> filters. I think that is error-prone/complex and fxp(4) can drop
> multicat frames until its filter is fully reprogrammed.
>
My setup on one side:
mskc0@pci0:1:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00
vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)'
class = network
subclass = ethernet
msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
...
media: Ethernet autoselect (100baseTX <full-duplex,flag0,flag1>)
status: active
The other side is:
fxp0@pci0:2:8:0: class=0x020000 card=0x00011179 chip=0x10318086 rev=0x42
hdr=0x00
vendor = 'Intel Corporation'
device = '82801CAM (ICH3) PRO/100 VE (LOM) Network Connection'
class = network
subclass = ethernet
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=2009<RXCSUM,VLAN_MTU,WOL_MAGIC>
...
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
Both sides:
~> uname -a
FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r194030M: Thu Jun 11 21:12:19 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64
The command used to receive packets (thanks to gnn):
./mctest -i msk0/fxp0 -m 0 -s 1024 -n 10000 -r
to transmit:
./mctest -i fxp0/msk0 -M 1 -s 1024 -n 10000 -t 1
The switch is CentreCOM FS709FC which
was disconnected from the uplink during the tests. That means that the
network was still idle other than test packets.
Looks like everything is working both with and without the patch.
However it seems I understand too little about multicasting to
perform sensible tests.
Do I need any
route add 224.0.0.0/4 -interface fxp0/msk0
commands?
How long should I wait before exchanging multicast transmitter with receiver?
...
ftp upload/download are working also good with/without the patch.
Alexey.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090617001527.GB4146>