From: Florian Fainelli <f.fainelli@gmail.com>
To: Claudiu Manoil <claudiu.manoil@freescale.com>
Cc: netdev <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH][net-next] gianfar: Fix reported number of sent bytes to BQL
Date: Tue, 03 Sep 2013 20:18:12 +0100 [thread overview]
Message-ID: <1943289.AeBmeBuHV2@lenovo> (raw)
In-Reply-To: <CAGVrzcaHLa1kT2wZc993cZFX2geQ4JgOO-u6JcWHFKcn-OZhZw@mail.gmail.com>
Le mardi 3 septembre 2013 19:59:42 Florian Fainelli a écrit :
> Hello Claudiu,
>
> 2013/8/30 Claudiu Manoil <claudiu.manoil@freescale.com>:
> > Fix the amount of sent bytes reported to BQL by reporting the
> > number of bytes on wire in the xmit routine, and recording that
> > value for each skb in order to be correctly confirmed on Tx
> > confirmation cleanup.
> >
> > Reporting skb->len to BQL just before exiting xmit is not correct
> > due to possible insertions of TOE block and alignment bytes in the
> > skb->data, which are being stripped off by the controller before
> > transmission on wire. This led to mismatch of (incorrectly)
> > reported bytes to BQL b/w xmit and Tx confirmation, resulting in
> > Tx timeout firing, for the h/w tx timestamping acceleration case.
> >
> > There's no easy way to obtain the number of bytes on wire in the Tx
> > confirmation routine, so skb->cb is used to convey that information
> > from xmit to Tx confirmation, for now (as proposed by Eric). Revived
> > the currently unused GFAR_CB() construct for that purpose.
>
> I do not see much difference between what this patch does and what the
> current net-next drivers does. If you need to correctly account for
> this, it seems to me like you should move the stats/bytes_sent
> computation below this line:
>
> if (unlikely(do_tstamp)) {
> skb_push(skb, GMAC_TXPAL_LEN);
> memset(skb->data, 0, GMAC_TXPAL_LEN);
> }
>
> to account for the SKB length update?
Just realized that this is precisely what your patch is fixing, sorry for the
noise.
--
Florian
next prev parent reply other threads:[~2013-09-03 19:18 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
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 [this message]
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=1943289.AeBmeBuHV2@lenovo \
--to=f.fainelli@gmail.com \
--cc=claudiu.manoil@freescale.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--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 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.