[Prism54-devel] Fragments for transmit; copy skbuf on receive?

[Herbert Valerio Riedel]

On Wed, Dec 31, 2003 at 03:13:07PM +0100, Jens Maurer wrote:
> Herbert Valerio Riedel wrote:
> Do we have a contact for the original driver authors so we can
> find out?

this is a question for mcgrof ...
 
> Even if the chipset can do frames larger than 1500 bytes, it still
> wouldn't make much sense to use fragmentation:  Just pass the full
> 8KB or so skbuff to the device and be done.  Unless the device
> is limited to 1500 bytes fragments in its DMA engine, which would
> seem very odd.

I agree with you here;
 
> I'm reading net/core/dev.c:dev_queue_xmit(), where it appears
> to be possible to tell the upper layers that our device does
> scatter/gather DMA, so fragmented skbuff's are ok, and if not,
> the skbuff gets linearized:
[...]
> If we wish to support that interface, that appears reasonable.

yeah, i know... i should have mentioned this possibility... but I
assumed we wanted to simplify the code... :-)

> Is there any chance to increase the size of the RX queue?
> #define ISL38XX_CB_RX_QSIZE                     8
> #define ISL38XX_CB_TX_QSIZE                     32

not really, afaik the shared memory structure holding the queue
pointers is hardcoded in the firmware (so _maybe_ it could be changed,
if we would know how to develop/code our own firmware...)
 
> I guess not, because we never pass the value to the device, so
> it seems fixed.  (A receive queue of length 8 is a little small
> for 54 Mbps on slow machines, I'd fathom.)

well, most hardware designs are not perfect... let's be thankful for
having those 8 slots all... as it could be much worse ;)

btw this small receive queue can be workarounded quite easily, by
having a fast interrupt handler which just copies over the full queue
entries into a 2nd queue... and do the actual processing of the
received frames at some lower priority...
 
> Is there some specification of the firmware interface available
> in text form?  Yes, I'm reading the IEEE MIBs, and that helps
> a little, but there's certainly more to it.

alas there's no freely distributable specification, since the firmware
is proprietary as well; 
 
> Btw, does anyone know what rx_data_high and tx_data_high from
> struct isl38xx_cb are supposed to be used for? They are not used
> in the driver, but their structure looks suspiciously similar
> to rx_data_low and tx_data_low, which is the main receive/transmit
> ring buffer.

I've been told it's there for future use (for OOB data and similiar
high-priority stuff) but not supported by the firmware yet; so far
only the low priority queues are used by the firmware;

regards,
-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org       /    Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142