Intel GigE and copper PHY supported?

[joe mcguckin]

We expect to push only 30 or 40 Mbits through it, so performance probably
won't be an issue. We're using a GigE interface because that's the only port
available on the ethernet switch we have to connect to.

joe


On 5/6/03 11:26 AM, "Jin Guojun [NCS]" <j_guojun at lbl.gov> wrote:

> "Simon L. Nielsen" wrote:
> 
>> On 2003.05.06 10:07:03 -0700, Jin Guojun [NCS] wrote:
>>> joe mcguckin wrote:
>>> 
>>>> I'd like to use the TYAN Trinity GC-SL motherboard with on-board GigE
>>>> (copper). Does anyone know if this is supported? Has anyone used this board
>>>> with 4.X?
>>>> 
>>>> Thanks,
>>> 
>>> Do not have direct use of this motherboard. We have some similar M/Bs
>>> from SuperMicro (same chipset and same GigE NICs).
>>> 
>>> General M/B performance is good. The GigE is not too pleasure.
>>> The Incoming TCP is about 350 Mb/s, and out going TCP is only 270,
>>> which is limited by interrupt (98% CPU -- 2.8 GHz -- used for interrupt).
>>> Either the driver or the Intel NIC is not functioning properly, but we do
>>> not
>>> have time to investigate.
>> 
>> If this the chips a using the em(4) driver you can try turning on
>> interrupt coalation (or whatever Intel calls it). It can (AFAIR) only be
>> done by modifying sys/dev/em/if_em.h. Just note the warning about why it
>> was disabled.
>> 
>> --
>> Simon L. Nielsen
> 
> The Tx interrupt coalescing in if_em.h in 4.8-RELEASE is enabled to 64 * 1.024
> us:
> /*
> * TxIntDelay
> * Valid Range: 0-65535 (0=off)
> * Default Value: 64
> *   This value delays the generation of transmit interrupts in units of
> *   1.024 microseconds. Transmit interrupt reduction can improve CPU
> *   efficiency if properly tuned for specific network traffic. If the
> *   system is reporting dropped transmits, this value may be set too high
> *   causing the driver to run out of available transmit descriptors.
> */
> #define EM_TIDV                         64
> 
> If this is really set, then the chip is not designed correctly. In my design
> experience,
> the Tx interrupt can only be generated after Tx queue is empty.
> The Tx  interrupt is generated immediately if TIDV = 0,
> or wait for TIDV * 1.024 us.
> 
> If the driver can feed the device enough data (also recycling the used
> buffers),
> Tx interrupt should never happen. This is different from Rx interrupt.
> 
> Two things can happen here, either the kernel does not provide enough data
> to the NIC, or the NIC generates interrupts anyway after TIDV regardless
> if the data queue is not empty. If it is the later case, I would blame Intel.
> We also have the  profermance issue on their 10Gb/s NIC, and we are still
> investigating what is the problem.
> 
>   -Jin
>