From: Ben Greear <greearb@candelatech.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: NetDev <netdev@vger.kernel.org>
Subject: Re: pktgen and spin_lock_bh in xmit path
Date: Mon, 19 Oct 2009 21:52:05 -0700 [thread overview]
Message-ID: <4ADD41F5.5080707@candelatech.com> (raw)
In-Reply-To: <4ADD32FA.6030409@gmail.com>
Eric Dumazet wrote:
> Ben Greear a écrit :
>
>> I'm having strange issues when running pktgen on 10G interfaces while
>> also running
>> pktgen on mac-vlans on that interface, when the mac-vlan pktgen threads
>> are on a different
>> CPU.
>>
>> First, lockdep gives up and says that things are not properly
>> annotated. I believe this is because
>> the macvlan tx path will lock it's txq and will also lock the
>> lower-dev's txq. To fix this, perhaps
>> we need some new lockdep aware primitives for netdev txq locking?
>>
>> Second, is using _bh() locking really sufficient if we have pktgen
>> writing to a physical device
>> and also have other pktgen threads writing to that same device though
>> mac-vlans? I'm seeing
>> deadlocks spinning on the _bh() lock in pktgen as well as strange
>> corruptions, so I think there
>> must be *some* problem somewhere, I just don't know quite what it is yet.
>>
>>
>
> Could you please give us a copy if your pktgen scripts ?
>
I'm driving it with another program, and my pktgen is a bit hacked, but
the basic idea is:
1 pktgen connection on cpu 0 running as fast as it can (trying for
10Gbps, but getting maybe 3-4),
running between two 10G ports (intel 82599).
Multi-pkt is set to 10,000 on each side.
3 pairs of mac-vlans on each of the two physical 10G ports.
3 pktgen 'connections' between these..each are running at about 1Gbps.
These 3 pktgen connections are on CPU 4.
Multi-pkt is set to 1 since multi-pkt is a very bad idea on virtual
devices.
1514 byte pkts. No IPs on the interfaces, using ToS in pktgen, but
nothing else is configured to
care.
The two physical ports are cabled together directly with a fibre cable.
All pktgen connections are full duplex (both sides transmitting to each
other..and I have
rx logic to gather stats on received pkts as well). With no kernel
debugging, this can run right at 10Gbps bi-directional,
with lockdep it gets around 5-6Gbps in each direction.
The lockup often occurs near starting/stopping pktgen, but also happens
while just normally
running under load, usually within 10 minutes.
I tried and failed to reproduce this on a 1G network, but maybe I'm just
not getting (un)lucky,
didn't try for too long.
Among other things, it appears as if the mac-vlan interfaces sometimes
become locked to transmit
by pktgen, but a raw socket in user-space can send on them fine. I'm
going to add some debugging
for this particular issue tomorrow to try to figure out why that happens.
Please note I have the rest of my network patches applied (but not using
any proprietary modules),
so it could easily be something I've caused. I think fixing lockdep to
work with the txq _bh locks
would be a good first step to fixing this..
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2009-10-20 4:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 3:38 pktgen and spin_lock_bh in xmit path Ben Greear
2009-10-20 3:48 ` Eric Dumazet
2009-10-20 4:52 ` Ben Greear [this message]
2009-10-20 17:37 ` Ben Greear
2009-10-20 17:44 ` Eric Dumazet
2009-10-20 17:54 ` Ben Greear
2009-10-20 18:35 ` Eric Dumazet
2009-10-20 18:54 ` Eric Dumazet
2009-10-20 20:16 ` Ben Greear
2009-10-20 21:10 ` Ben Greear
2009-10-20 21:22 ` Eric Dumazet
2009-10-20 21:30 ` Ben Greear
2009-10-20 21:57 ` Eric Dumazet
2009-10-20 23:17 ` Ben Greear
2009-10-21 3:05 ` Ben Greear
2009-10-21 3:12 ` Eric Dumazet
2009-10-21 3:59 ` Eric Dumazet
2009-10-21 5:00 ` Ben Greear
2009-10-21 5:14 ` Eric Dumazet
2009-10-21 5:40 ` Ben Greear
2009-10-21 5:12 ` Krishna Kumar2
2009-10-21 5:32 ` 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=4ADD41F5.5080707@candelatech.com \
--to=greearb@candelatech.com \
--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 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).