From: Ben Greear <greearb@candelatech.com>
To: Robert Olsson <Robert.Olsson@data.slu.se>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>,
hadi@cyberus.ca, netdev@oss.sgi.com
Subject: Re: inter-packet gap in pktgen
Date: Wed, 08 Dec 2004 11:32:14 -0800 [thread overview]
Message-ID: <41B756BE.3050504@candelatech.com> (raw)
In-Reply-To: <16822.54722.755218.745451@robur.slu.se>
Robert Olsson wrote:
> Lennert Buytenhek writes:
> >
> > Another option is:
> >
> > next_tx = get_time_in_ns();
> > while (--count) {
> > tx_packet();
> > next_tx += 1e9/intended_pps;
> > nanospin(next_tx - get_time_in_ns());
> > }
>
> Hello!
>
> I think this what Ben is doing with his userland app. Ev. adjusting
> the ipg delay in runtime? A kind of control system. Even the device
> stats could possible be read.
Actually, I do return virtually the entire pktgen_interface_info
structure through an IOCTL call. I do adjust the ipg often based on
what my control logic tells me I should do, 10 times a second I believe.
I found I needed external control because the control is fairly complex,
and I didn't want it in the kernel. I also aim to allow X number of
interfaces to be used at once, and allow a mixture of different speeds.
The traffic on the interfaces affect each other..so I found the external
control useful again...
All that said, when we do calculate the 'next-tx' timer in the kernel,
there is no reason I see not to use the method above to get as accurate as
possible.
> > This should be relatively independent of system load. OK, I know,
> > time to show some code.
>
> Also an idea might be to have some kind of option to use pktgen w.
> existent qdisc/tc infrastructure for this type of tests. Ben did
> you try this?
Actually, yes. My pktgen no longer busy-spins. I probably add a bit
of jitter at a very low level, but over all system performance is much
better. I use a callback from net_device.h to wake up the pktgen thread,
and I put it to sleep as soon as I have no more work to do, or I get
a hard-start-xmit error. The netdev.h code looks like this:
@@ -474,9 +482,18 @@
void (*poll_controller)(struct net_device *dev);
#endif
+ /* Callback for when the queue is woken, used by pktgen currently */
+ int (*notify_queue_woken)(struct net_device *dev);
+ void* nqw_data; /* To be used by the method above as needed */
+
/* bridge stuff */
struct net_bridge_port *br_port;
static inline void netif_wake_queue(struct net_device *dev)
{
#ifdef CONFIG_NETPOLL_TRAP
if (netpoll_trap())
return;
#endif
if (test_and_clear_bit(__LINK_STATE_XOFF, &dev->state)) {
__netif_schedule(dev);
if (dev->notify_queue_woken) {
dev->notify_queue_woken(dev);
}
}
}
pktgen registers with devices' notify_queue_woken hook. For VLANs, I have some fairly complex
logic in pktgen so that it still registers with the 'real' device
since the VLAN won't have the netif_wake_queue called when the
real device drains it's fifo.
I'd be happy to have this included in the kernel, or be a basis for something
similar, so let me know if you'd like to see the full patch. It is unlikely
that davem will allow my pktgen-rx code in as well, but the tx stuff might
still prove useful.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2004-12-08 19:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-07 22:25 inter-packet gap in pktgen Lennert Buytenhek
2004-12-07 22:47 ` Ben Greear
2004-12-08 7:38 ` Lennert Buytenhek
2004-12-08 10:21 ` Robert Olsson
2004-12-08 11:15 ` Lennert Buytenhek
2004-12-08 19:32 ` Ben Greear [this message]
2004-12-10 22:29 ` Lennert Buytenhek
2004-12-10 23:01 ` Ben Greear
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=41B756BE.3050504@candelatech.com \
--to=greearb@candelatech.com \
--cc=Robert.Olsson@data.slu.se \
--cc=buytenh@wantstofly.org \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.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.