All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ben Greear <greearb@candelatech.com>
Cc: NetDev <netdev@vger.kernel.org>
Subject: [PATCH net-next-2.6] pktgen: tx_bytes might be slightly wrong
Date: Thu, 05 Nov 2009 06:20:59 +0100	[thread overview]
Message-ID: <4AF260BB.6070607@gmail.com> (raw)
In-Reply-To: <4AF236D1.7020006@candelatech.com>

From: Ben Greear <greearb@candelatech.com>

Ben Greear a écrit :
> There is a subtle bug in pktgen tx_bytes accounting.
> 
> If one is using clone_skb, then the cur_pkt_size may be modified
> without a new skb actually being created (quite yet) by setting
> min_pkt_size through the proc fs.
> 
> I think if you just saved pkt_dev->skb->len before transmitting and used
> that to increment pkt_dev->tx_bytes that would fix the counter
> problem.
> 
>     if (unlikely(netif_tx_queue_stopped(txq) ||
> netif_tx_queue_frozen(txq)))
>         ret = NETDEV_TX_BUSY;
>     else
>         ret = (*xmit)(pkt_dev->skb, odev);
> 
>     switch (ret) {
>     case NETDEV_TX_OK:
>         txq_trans_update(txq);
>         pkt_dev->last_ok = 1;
>         pkt_dev->sofar++;
>         pkt_dev->seq_num++;
>         pkt_dev->tx_bytes += pkt_dev->cur_pkt_size;
>         break;
> 
> 

Hi Ben

Nice catch :)

Note that clone_skb>0 makes the race window bigger, but its also racy for clone_skb=0

Instead of storing pkt_dev->skb->len in a temporary variable,
we could store it in pkt_dev->last_pkt_size, it'll be a bit faster.

[PATCH net-next-2.6] pktgen: tx_bytes might be slightly wrong

cur_pkt_size can be changed in proc fs while pktgen is running,
we better use a private field to get precise tx-bytes counter.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---

diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 5ce017b..d38470a 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -340,6 +340,7 @@ struct pktgen_dev {
 	__u16 cur_udp_src;
 	__u16 cur_queue_map;
 	__u32 cur_pkt_size;
+	__u32 last_pkt_size;
 
 	__u8 hh[14];
 	/* = {
@@ -3434,7 +3435,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
 			pkt_dev->clone_count--;	/* back out increment, OOM */
 			return;
 		}
-
+		pkt_dev->last_pkt_size = pkt_dev->skb->len;
 		pkt_dev->allocated_skbs++;
 		pkt_dev->clone_count = 0;	/* reset counter */
 	}
@@ -3461,7 +3462,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
 		pkt_dev->last_ok = 1;
 		pkt_dev->sofar++;
 		pkt_dev->seq_num++;
-		pkt_dev->tx_bytes += pkt_dev->cur_pkt_size;
+		pkt_dev->tx_bytes += pkt_dev->last_pkt_size;
 		break;
 	default: /* Drivers are not supposed to return other values! */
 		if (net_ratelimit())

  reply	other threads:[~2009-11-05  5:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-05  2:22 Small pktgen bug Ben Greear
2009-11-05  5:20 ` Eric Dumazet [this message]
2009-11-06  5:08   ` [PATCH net-next-2.6] pktgen: tx_bytes might be slightly wrong David Miller

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=4AF260BB.6070607@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=greearb@candelatech.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.