On Thursday 12 January 2006 18:58, Andreas Mohr wrote:
> Hi,
>
> I'd like to ask some things about packet fragmentation (you remember I wanted
> to work on this due to my very bad link quality?). I'm asking now since I
> will probably have some time during the weekend to work on it.
>
> Problem is that fragmenting packets requires allocating several tx descriptors
> in a row, then preparing and sending the data packet piecemeal via those
> various descriptors in acx_l_tx_data().
> Do you have any recommendations on how to do it?
> (the split between acx_l_alloc_tx() and acx_l_tx_data() is a bit problematic)
Basically you want to modify this part of acx_i_start_xmit():
tx = acx_l_alloc_tx(priv);
if (unlikely(!tx)) {
printk_ratelimited("%s: start_xmit: txdesc ring is full, "
"dropping tx\n", dev->name);
txresult = NOT_OK;
goto end;
}
txbuf = acx_l_get_txbuf(priv, tx);
if (unlikely(!txbuf)) {
/* Card was removed */
txresult = NOT_OK;
acx_l_dealloc_tx(priv, tx);
goto end;
}
len = acx_ether_to_txbuf(priv, txbuf, skb);
if (unlikely(len < 0)) {
/* Error in packet conversion */
txresult = NOT_OK;
acx_l_dealloc_tx(priv, tx);
goto end;
}
acx_l_tx_data(priv, tx, len);
As seen here, current code produces and tx'es just one wlan packet.
Possible adaptation:
struct frag_vec {
int len;
void *tx;
void *txbuf;
};
/* allocates and fills from 1 to N wlan fragments */
int acx_ether_to_frags(wlandevice_t *priv, const struct sk_buff *skb, struct
frag_vec *frag, int len);
acx_i_start_xmit():
struct frag_vec frag[N];
...
n = acx_ether_to_frags(priv, skb, frag, N);
if (n <= 0) {
/* Error in packet conversion */
txresult = NOT_OK;
goto end;
}
for(1..n)
acx_l_tx_data(priv, frag[i].tx, frag[i].len);
> Or should this be the job of the OS to care about fragmenting the packets
> to be sent? (then it would just call our data tx stuff multiple times itself
> anyway).
Yes, it must be done by softmac layer.
> And what about the multiple host txhostdescs that we (need to?) initialize
> in order to work around "bugs"?
It should not matter here, you won't even need to touch pci.c
except for maybe setting some FIRSTFRAG and/or MORE_FRAG bits
as appropriate.
> Are we sure that this is a bug of specific(???) cards or not simply a bug of
> certain firmware versions or even a bug in our driver? (maybe due to doing
> some things in weird ways that the firmware totally doesn't expect?).
I think firmware was debugged only to meet needs of Windows driver.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
