Re: re0 fix that works with polling

On Sun, 2004-10-17 at 18:12, John-Mark Gurney wrote:
> John-Mark Gurney wrote this message on Sun, Oct 17, 2004 at 16:28 -0700:
> > I'll do some tests shortly to see about these issues...
> 
> Ok, I played around w/ rwatson's netsend program, and I was able to
> send 1316 byte payload udp packets at about 28kpps w/o problems.. I
> was not able to confirm that no packets were loss, BUT, netstat did
> show very close to 28kpps received...  At 28kpps, it's far exceeds
> your problem of 15Mbps, it is about 38megbytes/sec..

I looked at netsend a little and it looks like a nice little tool.  I
assume there is a program for the other side as well?  I just glanced at
it, so apologies if it work on either end.  My testing was slightly
different in that I am sending udp _multicast_ packets.  I've been using
vls to push the data out and I do not know how it behaves with sockets
(Perhaps it is writing with no delay as opposed to waiting for the lower
layer to push the data out).  I honestly do not know.  I also assume
that you have been testing with the nic set to 1000BT (gigE)? Seems like
it from the xfer rate.  There are no issues when it is going out 100BT.

> What does your dmesg say about your re0?
> 
> Mine is:
> re0: <RealTek 8169S Single-chip Gigabit Ethernet> port 0xe000-0xe0ff mem 0xe8002000-0xe80020ff irq 11 at device 11.0 on pci0
> re0: Ethernet address: 00:50:fc:f7:5b:d0

And mine says:

re0: <RealTek 8169S Single-chip Gigabit Ethernet> port 0xcc00-0xccff mem 0xcfffb300-0xcfffb3ff irq 16 at device 11.0 on pci0
miibus1: <MII bus> on re0
rgephy0: <RTL8169S/8110S media interface> on miibus1
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto
re0: Ethernet address: 00:0c:76:e9:2c:58

It is running on its own irq.

> and it's more specificly a 32-bit ConnectGear G30TX-32.

Mine is on my amd64 mobo.  I'm running native amd64 freebsd.

To answer a previous email (quoted here...)

> Ok, interesting...  now are you sure that adding re_txeof in
> re_start is better than properly fixing it so that we can make use
> of the extra tx descriptors that the 8169 supports?  Right now it is
> hardcoded to 64 because that is all that the 8110 supports iirc, but
> the 8164 supports upto 1024 tx descriptors...

I really didn't need to add the re_txeof in re_send I don't think.  My
main issue with polling appears to be that HZ=1000 doesn't seem to cause
draining of the tx buffers fast enough.  I had to keep the tx timer to
ensure that.  On the receive side I have no idea either.  I've only
tested xmit.

> Also, do you know of the tx timer changes fire rate dependant upon
> the speed of the link..  the 8169 data sheet gives no specifics on
> what the rate of the time is and approrpriate values..

Not a clue.  Sorry.  It would explain the failure to work with 1000BT
vs. 100BT.  Except it doesn't make sense.  The timer running slower at
the higher rate interface?

Thanks for looking into this, John-Mark.

Sean