Intel GigE and copper PHY supported?

[Jin Guojun [NCS]]

"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