On Oct 21, 2005, at 8:33 AM, Lee Sharp wrote:

> From: "Jim Thompson" <jim at netgate dot com>
>
>
>> On Oct 21, 2005, at 6:53 AM, Lee Sharp wrote:
>>
>
>
>>> And keep in mind that the onboard VIA ether ports are in the  
>>> same  class as the D-link...
>>>
>
>
>> Could you "show your work" here?   Do they fail at throughput  
>> tests,  or suddenly go off-line, or somehow fail in-service?
>>
>
>
>> Or is this one of those, "If its not Intel or 3Com, it must suck"   
>> things?
>>
>
> Actually, I was trying to avoid the realtek is buggy, no it is not  
> jihad. :-)  Intel has a driver that leaves a lot of the heavy  
> lifting on the card. So does 3-com.  Most cheap NICs leave a lot of  
> the heavy lifting to the CPU. Personally, I like Intel, but YMMV.

The VIA Rhine (the chipsets found on board the Via board that you  
disparaged) strongly resemble the DEC Tulip design that is about as  
good as it
gets without a bunch of work at the chipset for TCP checksum off- 
load, coalesce interrupts, etc.  The only 'bad' thing about the Rhine  
is this comment by Bill Paul in the driver source:

* The Rhine has a serious flaw in its transmit DMA mechanism:
* transmit buffers must be longword aligned. Unfortunately,
* FreeBSD doesn't guarantee that mbufs will be filled in starting
* at longword boundaries, so we have to do a buffer copy before
* transmission.


The "Good Intel NIC" you pointed to uses an Intel 82550EY chipset.   
There isn't any support I know of in FreeBSD 4.11 (i.e. 'm0n0wall')  
for the IPSEC offloading that the Intel 82550EY supports, though the  
fxp driver does support this chip.

There is this comment in the fxp(4) man page (for 6.0.  I don't have  
a full install of 4.11 anywhere.):

     Some chip revisions have loadable microcode which can be used to  
reduce the interrupt load on the host cpu.  Not all boards have
     microcode support.  Setting the link0 flag with ifconfig(8) will  
download the microcode to the chip if it is available.

This support basically coalesce interrupts, with two exceptions.  You  
can set a dead-man timer, such that an interrupt happens after a  
given number of, you can set the maximum number of frames to coalesce  
and you can set a 'ceiling' such that any frame smaller than N bytes  
results in an immediate interrupt.

The 82550E is one of those that doesn't have such support (according  
to the driver in 6.0 RC1, anyway.)

if_fxpreg.h:

#define FXP_REV_82557               1       /* catchall 82557 chip  
type */
#define FXP_REV_82558_A4    4       /* 82558 A4 stepping */
#define FXP_REV_82558_B0    5       /* 82558 B0 stepping */
#define FXP_REV_82559_A0    8       /* 82559 A0 stepping */
#define FXP_REV_82559S_A    9       /* 82559S A stepping */
#define FXP_REV_82550               12
#define FXP_REV_82550_C             13      /* 82550 C stepping */
#define FXP_REV_82551_E             14      /* 82551 */
#define FXP_REV_82551_F             15      /* 82551 */
#define FXP_REV_82551_10    16      /* 82551 */

(The 82551 types aren't in the 4.11 version of the driver)

if_fxp.c:

struct ucode {
         uint32_t        revision;
         uint32_t        *ucode;
         int             length;
         u_short         int_delay_offset;
         u_short         bundle_max_offset;
} ucode_table[] = {
         { FXP_REV_82558_A4, UCODE(fxp_ucode_d101a),  
D101_CPUSAVER_DWORD, 0 },
         { FXP_REV_82558_B0, UCODE(fxp_ucode_d101b0),  
D101_CPUSAVER_DWORD, 0 },
         { FXP_REV_82559_A0, UCODE(fxp_ucode_d101ma),
             D101M_CPUSAVER_DWORD, D101M_CPUSAVER_BUNDLE_MAX_DWORD },
         { FXP_REV_82559S_A, UCODE(fxp_ucode_d101s),
             D101S_CPUSAVER_DWORD, D101S_CPUSAVER_BUNDLE_MAX_DWORD },
         { FXP_REV_82550, UCODE(fxp_ucode_d102),
             D102_B_CPUSAVER_DWORD, D102_B_CPUSAVER_BUNDLE_MAX_DWORD },
         { FXP_REV_82550_C, UCODE(fxp_ucode_d102c),
             D102_C_CPUSAVER_DWORD, D102_C_CPUSAVER_BUNDLE_MAX_DWORD },
         { FXP_REV_82551_F, UCODE(fxp_ucode_d102e),
             D102_E_CPUSAVER_DWORD, D102_E_CPUSAVER_BUNDLE_MAX_DWORD },
         { 0, NULL, 0, 0, 0 }
};

In the 4.11 driver there is logic to support the interrupt coalesce  
function, but they are set to default values.  These are exposed via  
sysctl, but I doubt that m0n0wall goes out of its way to make these  
EZ to change.   (The 'auto setup' via 'ifconfig fxpN link0' isn't in  
FreeBSD 4.11.)  (I haven't checked to see if pfSense sets link0.)

The dual-port adapter you reference has a pair of 82558B chips on  
it.  These do support the interrupt coalesce function, but you need  
an 82559 to get extended TxCBs, which can enable TX checksum  
generation (not supported in FreeBSD 4.11 anyway), VLAN offload, etc.

So, do you still want to state, "Intel has a driver that leaves a lot  
of the heavy lifting on the card. " ?  Its a true statement, just not  
for these cards.  :-)

Jim