re(4) needs promisc to work properly

[Bill Paul]

> * Bill Paul <wpaul at 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