Date: Fri, 1 Dec 2006 00:16:57 +0000 (GMT) From: wpaul@FreeBSD.ORG (Bill Paul) To: ed@fxq.nl (Ed Schouten) Cc: pyunyh@gmail.com, stable@freebsd.org, net@freebsd.org Subject: Re: re(4) needs promisc to work properly Message-ID: <20061201001657.9F44E16A407@hub.freebsd.org> In-Reply-To: <20061130210524.GY16100@hoeg.nl> from Ed Schouten at "Nov 30, 2006 10:05:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> * Bill Paul <wpaul@FreeBSD.ORG> wrote: > > > It's more likely a problem with the multicast filter programming. > > > IPv6 is all about the multicasting (neighbord discovery depends on it > > > to work correctly). I can't explain why it's not working though. > > > I've tested the sample 8168B/8111B cards that RealTek sent me, and I > > > didn't have any multicast problems with them. > > > > > > -Bill > > > > I guess I wasn't diligent enough in my testing. Upon closer inspection > > of the documentation, it appears RealTek abitrarily decided to > > reverse the order of the multicast hash registers in the PCIe parts: > > you have to write the hash table out in reverse order. > > > > I have no idea why they did this. In any case, I'm attaching a patch > > which should fix the problem. > > It does. Thanks a lot. I still have some other minor issues with my > network interface by the way: > > - Switching from and to promiscuous mode takes 7 seconds. All packets > are dropped in the mean time. The SIOCSIFFLAGS handler in re_ioctl() currently just takes a shortcut of calling re_init(). While this does eventually end up changing the RX filter settings accordingly, it takes a while because re_init() also shuts down and re-initializes the whole chip (including resetting the link). This is relatively easy to fix though. The IFF_PROMISC flag can be singled out and handled separately. (A few other drivers already do this.) > - Fetching 100 Mbit through FTP uses a lot of interrupts (almost > thousands). Assuming that "almost thousands" means "less than 1000," that's actually pretty good. Assuming full size (1500 byte) frames, it takes about 8100 frames/second to fill a 100Mbps pipe. Each time a frame arrives, you get an RX completion interrupt. You'll also get a TX completion interrupt when TCP ACKs the incoming data. A hastily contrived test using ttcp between my SunBlade and dual PIII FreeBSD 6.1 workstation here in my office using ttcp shows that my fxp interface is generating anywhere from 7800 to 8180 interrupts per second (according to "systat -vmstat 1"), which seems to agree with my math. As soon as the re_intr() routine is invoked by an interrupt, it'll mask interrupts and schedule RX and TX handling to be done in a taskqueue. The taskqueue will keep draining interrupt events until no more are pending, and only then will it unmask interrupts again. This cuts down on interrupt overhead somewhat, which is always a good thing. (Interrupt moderation can help too, but the RealTek chip doesn't support it.) So consider yourself lucky: there are CPU-starved children in africa who'd be overjoyed to only have to handle hundreds of interrupts per second. -Bill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061201001657.9F44E16A407>