From: Claudiu Manoil <claudiu.manoil@freescale.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <netdev@vger.kernel.org>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH][net-next] gianfar: Fix reported sent bytes to BQL for Tx timestamping
Date: Mon, 29 Apr 2013 18:52:34 +0300 [thread overview]
Message-ID: <517E9742.1010002@freescale.com> (raw)
In-Reply-To: <1367249315.8964.314.camel@edumazet-glaptop>
On 4/29/2013 6:28 PM, Eric Dumazet wrote:
> On Mon, 2013-04-29 at 08:23 -0700, Eric Dumazet wrote:
>> On Mon, 2013-04-29 at 17:27 +0300, Claudiu Manoil wrote:
>>> Hi,
>>>
>>> Unfortunately fixing this the other way around would imply changes
>>> in both xmit and clean_tx, and additional overhead in clean_tx.
>>> On xmit skb->len gets incremented with FCB_LEN and/or TXPAL_LEN,
>>> on a case by case basis. This would imply to add extra checks on
>>> clean_tx to identify whether only FCB_LEN has been added, or
>>> FCB+TXPAL or neither, all these just to report the bytes on wire
>>> for BQL.
>>> Does BQL really need to measure the bytes-on-wire or the bytes consumed
>>> for buffering?
>>
>> Yes.
>>
>> What about :
>>
>> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
>> index 2375a01..bb727e1 100644
>> --- a/drivers/net/ethernet/freescale/gianfar.c
>> +++ b/drivers/net/ethernet/freescale/gianfar.c
>> @@ -2065,6 +2065,7 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
>> u32 bufaddr;
>> unsigned long flags;
>> unsigned int nr_frags, nr_txbds, length, fcb_length = GMAC_FCB_LEN;
>> + unsigned int len;
>>
>> /* TOE=1 frames larger than 2500 bytes may see excess delays
>> * before start of transmission.
>> @@ -2130,7 +2131,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
>> }
>>
>> /* Update transmit stats */
>> - tx_queue->stats.tx_bytes += skb->len;
>> + len = skb->len;
Already tried this change in xmit, but it breaks the UDP/TCP cases (eg.
ftp). Due to (skb->ip_summed == CHECKSUM_PARTIAL) condition FCB is
added on xmit (skb->len increased with FCB_LEN only), and Tx completion
does not make this check.
> Idea is to use this value in TX completion.
>
> If at tx completion skb->len might be different, then store the true
> skb->len in skb->cb[]
>
Interesting but non-trivial, I think. Is this allowed? I mean, doesn't
the net stack overwrite this field?
Thanks,
Claudiu
next prev parent reply other threads:[~2013-04-29 15:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 12:57 [PATCH][net-next] gianfar: Fix reported sent bytes to BQL for Tx timestamping Claudiu Manoil
2013-04-29 13:53 ` Eric Dumazet
2013-04-29 14:27 ` Claudiu Manoil
2013-04-29 15:23 ` Eric Dumazet
2013-04-29 15:28 ` Eric Dumazet
2013-04-29 15:39 ` Eric Dumazet
2013-04-29 15:42 ` Eric Dumazet
2013-04-29 15:52 ` Claudiu Manoil [this message]
2013-04-29 15:59 ` Eric Dumazet
2013-08-30 12:01 ` [PATCH][net-next] gianfar: Fix reported number of sent bytes to BQL Claudiu Manoil
2013-09-03 18:59 ` Florian Fainelli
2013-09-03 19:18 ` Florian Fainelli
2013-09-04 2:14 ` David Miller
2013-04-29 15:33 ` [PATCH][net-next] gianfar: Fix reported sent bytes to BQL for Tx timestamping Eric Dumazet
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=517E9742.1010002@freescale.com \
--to=claudiu.manoil@freescale.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.