Netdev List
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@ilport.com.ua>
To: acx100-devel@lists.sourceforge.net, netdev@vger.kernel.org
Cc: Andreas Mohr <andim2@users.sourceforge.net>
Subject: Re: Tx packet fragmentation?
Date: Fri, 13 Jan 2006 13:00:39 +0200	[thread overview]
Message-ID: <200601131300.39276.vda@ilport.com.ua> (raw)
In-Reply-To: <20060112165853.GA17789@rhlx01.fht-esslingen.de>

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

           reply	other threads:[~2006-01-13 11:00 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20060112165853.GA17789@rhlx01.fht-esslingen.de>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200601131300.39276.vda@ilport.com.ua \
    --to=vda@ilport.com.ua \
    --cc=acx100-devel@lists.sourceforge.net \
    --cc=andim2@users.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox