Re: NAPI for eepro100

Re: NAPI for eepro100

[Donald Becker]

On Wed, 12 Jun 2002, David S. Miller wrote:
>    From: Jeff Garzik <jgarzik@mandrakesoft.com>
>    Oh crap, you're right...   eepro100 in general does funky stuff with the
>    way packets are handled, mainly due to the need to issue commands to the
>    NIC engine instead of the normal per-descriptor owner bit way of doing
>    things.

The eepro100 has a unique design in many different aspects.

> The question is, do the descriptor bits have to live right before
> the RX packet data buffer or can other schemes be used?

With the current driver structure, yes, the descriptor words must be
immediately before the packet data.  You can use other Rx and Tx
structures/modes to avoid this, but they use less efficient memory access.
For instance, the current Tx structure allows transmitting a packet with
a single PCI burst, rather than multiple transfers.


-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993

Re: NAPI for eepro100

[Jeff Garzik]

Zhang Fuxin wrote:
> hi,all
>   Recently i've converted eepro100 driver to use napi,in order to improve
> network performance of my poor 150M mips machine. It does eliminate
> the interrupt live lock seen before,maintaining a peak throughput under
> heavy load.
>  In case anybody are interested,i post the patches to the list. They are
> 3 incremental patchs:
>   eepro100-napi.patch is against 2.5.20 eepro100.c and provide basic
> napi support

Nifty, I'll take a look at this.


>   eepro100-proc.patch is proc file system support adapted from intel's
> e100 driver. I am using it for debugging.
>   eepro100-mips.patch is mips specific patch to make it work(well) for 
> my mips
> platform.


Just FWIW I'm not gonna apply these... for the 'proc' patch, that either 
needs to be moved to ethtool, or we should make a filesystem for net 
drivers that exports procfs-like inodes.  for the 'mips' patch, it looks 
like the arch maintainer(s) need to fix the PCI DMA support...

	Jeff

Re: NAPI for eepro100

[David S. Miller]

   From: Jeff Garzik <jgarzik@mandrakesoft.com>
   Date: Wed, 12 Jun 2002 19:00:00 -0400
   
   for the 'mips' patch, it looks 
   like the arch maintainer(s) need to fix the PCI DMA support...

No, it's worse than that.

See how non-consistent memory is used by the eepro100 driver
for descriptor bits?  The skb->tail bits?

That is very problematic.

Re: NAPI for eepro100

[Jeff Garzik]

David S. Miller wrote:
>    From: Jeff Garzik <jgarzik@mandrakesoft.com>
>    Date: Wed, 12 Jun 2002 19:00:00 -0400
>    
>    for the 'mips' patch, it looks 
>    like the arch maintainer(s) need to fix the PCI DMA support...
> 
> No, it's worse than that.
> 
> See how non-consistent memory is used by the eepro100 driver
> for descriptor bits?  The skb->tail bits?
> 
> That is very problematic.


Oh crap, you're right...   eepro100 in general does funky stuff with the 
way packets are handled, mainly due to the need to issue commands to the 
NIC engine instead of the normal per-descriptor owner bit way of doing 
things.

Well, I accept patches to that clean eepro100 up...   I'm not terribly 
motivated to clean it up myself, as we have e100 and an e100 maintainer 
we can beat on if such uglies arise :)

	Jeff

Re: NAPI for eepro100

[David S. Miller]

   From: Jeff Garzik <jgarzik@mandrakesoft.com>
   Date: Wed, 12 Jun 2002 19:17:58 -0400

   Oh crap, you're right...   eepro100 in general does funky stuff with the 
   way packets are handled, mainly due to the need to issue commands to the 
   NIC engine instead of the normal per-descriptor owner bit way of doing 
   things.

The question is, do the descriptor bits have to live right before
the RX packet data buffer or can other schemes be used?

Re: NAPI for eepro100

[David S. Miller]

   From: Andrey Savochkin <saw@saw.sw.com.sg>
   Date: Thu, 13 Jun 2002 12:57:53 +0400

   On Wed, Jun 12, 2002 at 04:05:32PM -0700, David S. Miller wrote:
   > No, it's worse than that.
   > 
   > See how non-consistent memory is used by the eepro100 driver
   > for descriptor bits?  The skb->tail bits?
   > 
   > That is very problematic.
   
   What's the problem?
   If it isn't allowed to do, then what is the meaning of PCI_DMA_BIDIRECTIONAL
   mappings?

It's slow.  Not wrong, just inefficient.

Descriptors were meant to be done using consistent mappings, not
"pci_map_*()"'d memory.  The latter is meant to be used for long
linear DMA transfers to/from the device.  It is not meant for things
the cpu pokes small bits of data in and out of, that is what
consistent DMA memory is for.

Re: NAPI for eepro100

[Andrey Savochkin]

On Wed, Jun 12, 2002 at 04:05:32PM -0700, David S. Miller wrote:
>    From: Jeff Garzik <jgarzik@mandrakesoft.com>
>    Date: Wed, 12 Jun 2002 19:00:00 -0400
>    
>    for the 'mips' patch, it looks 
>    like the arch maintainer(s) need to fix the PCI DMA support...
> 
> No, it's worse than that.
> 
> See how non-consistent memory is used by the eepro100 driver
> for descriptor bits?  The skb->tail bits?
> 
> That is very problematic.

What's the problem?
If it isn't allowed to do, then what is the meaning of PCI_DMA_BIDIRECTIONAL
mappings?

	Andrey