linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: <netdev@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Felix Fietkau <nbd@openwrt.org>,
	Jesper Dangaard Brouer <jbrouer@redhat.com>
Subject: Re: linux-3.14-rc1 & PACKET_QDISC_BYPASS : slow_path warning
Date: Tue, 4 Feb 2014 14:13:21 +0100	[thread overview]
Message-ID: <52F0E771.8070904@fokus.fraunhofer.de> (raw)
In-Reply-To: <52F0E361.9000304@redhat.com>

Hi Daniel,

On 02/04/2014 01:56 PM, Daniel Borkmann wrote:
> Hi Mathias, [cc'ing Felix]
>
> On 02/03/2014 11:47 PM, Mathias Kretschmer wrote:
>> Hi Daniel,
>>
>> we are developing a wired/wireless MPLS switch. Currently the data plane runs in
>> user space using PF_PACKET sockets via RX_RING/TX_RING.
>>
>> We had hoped to test the PACKET_QDISC_BYPASS option since this seems to be the
>> proper optimization for our purposes.
>>
>> Unfortunately, we're seeing a 'slow path' warning for every packet that is being
>> sent out. With PACKET_QDISC_BYPASS disabled, no warnings are dumped. Hardware is
>> an older AMD Geode LX embedded board (ALiX).
>>
>> BTW, this happens while sending via a wireless (802.11) adhoc interface. Hence, it
>> might be an interaction with the ieee80211 sub system.
>
> Hm, so the WARN_ON() is triggered inside ath9k driver in relation to 802.11 QoS,
> and came in from commit 066dae93bdf ("ath9k: rework tx queue selection and fix
> queue stopping/waking"). We did the stress testing of that option for PF_PACKET
> on 10Gbit/s NICs. Seems to me you might be running into the same issue when using
> pktgen as it randomly or per round-robin selects tx queues as well? Not entirely
> sure how necessary this WARN_ON() is though, Felix? I think QDISC_BYPASS might not
> be the best option in your case, perhaps you will run into increased power usage
> in your NIC as a side-effect?

I'm not familiar with the exact implementation details, but from the description of 
this option, it seems to me that this is exactly what one would want to use if the 
goal is to send an Ethernet frame out on a particular interface without any further 
processing by the kernel.

Why would this increase the power usage on the NIC ?  Due to a higher achievable 
packet rate ?  That would be acceptable :)

Cheers,

Mathias


> Cheers,
>
> Daniel


  reply	other threads:[~2014-02-04 13:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 22:47 linux-3.14-rc1 & PACKET_QDISC_BYPASS : slow_path warning Mathias Kretschmer
2014-02-04 12:56 ` Daniel Borkmann
2014-02-04 13:13   ` Mathias Kretschmer [this message]
2014-02-04 14:25     ` Daniel Borkmann
2014-02-04 14:35       ` Mathias Kretschmer
2014-02-04 14:48         ` Felix Fietkau
2014-02-04 22:17           ` Daniel Borkmann

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=52F0E771.8070904@fokus.fraunhofer.de \
    --to=mathias.kretschmer@fokus.fraunhofer.de \
    --cc=dborkman@redhat.com \
    --cc=jbrouer@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@openwrt.org \
    --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).