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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).