netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Bohrer <sbohrer@rgmadvisors.com>
To: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Cc: Amir Vadai <amirv@mellanox.com>, netdev@vger.kernel.org
Subject: Re: low latency/busy poll feedback and bugs
Date: Tue, 6 Aug 2013 13:08:06 -0500	[thread overview]
Message-ID: <20130806180806.GA8993@sbohrermbp13-local.rgmadvisors.com> (raw)
In-Reply-To: <5200A8BC.4010402@linux.intel.com>

On Tue, Aug 06, 2013 at 10:41:48AM +0300, Eliezer Tamir wrote:
> On 06/08/2013 00:22, Shawn Bohrer wrote:
> > 3) I don't know if this was intentional, an oversight, or simply a
> > missing feature but UDP multicast currently is not supported.  In
> > order to add support I believe you would need to call
> > sk_mark_napi_id() in __udp4_lib_mcast_deliver().  Assuming there isn't
> > some intentional reason this wasn't done I'd be happy to test this and
> > send a patch.
> 
> This is still WIP, so our goal was to make it easy to extend for new
> cases and protocols.
> 
> For multicast, it is possible that incoming packets to come from more
> than one port (and therefore more than one queue).
> I'm not sure how we could handle that, but what we have today won't do
> well for that use-case.
 
It is unclear to me exactly what happens in this case.  With my simple
patch I'm assuming it will spin on the receive queue that received the
last packet for that socket.  What happens when a packet arrives on a
different receive queue than the one we were spinning on? I assume it
is still delivered but perhaps the spinning process won't get it until
the spinning time expires?  I'm just guessing and haven't attempted to
figure it out from looking through the code.

I put together a small test case with two senders and a single
receiver, and visually (by watching /proc/interrups) verified that
their traffic went to two different queues.  The receiver received all
of the packets with busy_read enabled so it appears that it at least
superficially works.  I did not verify the effect on latency.

> What do you use for testing?

In fio 2.1.2 [1] I added support for UDP multicast.  It's not quite as
flexible as I would like but you can still test a number of scenarios
like the one above or do a basic pingpong test.

Here are my fio job files for a pingpong test:

$ cat mcudp_rr_receive
[global]
ioengine=net
protocol=udp
bs=64
size=100m
# IP address of interface to receive packets
#interface=10.8.16.21
rw=read

[pingpong]
pingpong=1
port=10000
hostname=239.0.0.0

$ cat mcudp_rr_send
[global]
ioengine=net
protocol=udp
bs=64
size=100m
# IP address of interface to send packets
#interface=10.8.16.22
rw=write

[pingpong]
pingpong=1
port=10000
hostname=239.0.0.0

Just start the receiver on one host then start the sender on a second
host:

[host1] $ fio mcudp_rr_receive

[host2] $ fio mcudp_rr_send

[1] http://brick.kernel.dk/snaps/fio-2.1.2.tar.bz2

--
Shawn

-- 

---------------------------------------------------------------
This email, along with any attachments, is confidential. If you 
believe you received this message in error, please contact the 
sender immediately and delete all copies of the message.  
Thank you.

  reply	other threads:[~2013-08-06 18:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 21:22 low latency/busy poll feedback and bugs Shawn Bohrer
2013-08-05 22:16 ` [PATCH net-next] net: Add low-latency/polling support for UDP multicast Shawn Bohrer
2013-08-06  7:13   ` Eliezer Tamir
2013-08-06 19:51     ` [PATCH v2 " Shawn Bohrer
2013-08-07 20:22       ` Eric Dumazet
2013-08-08  8:46         ` Eliezer Tamir
2013-08-08 23:55           ` Eric Dumazet
2013-08-11  7:59             ` Eliezer Tamir
2013-08-06  7:41 ` low latency/busy poll feedback and bugs Eliezer Tamir
2013-08-06 18:08   ` Shawn Bohrer [this message]
2013-08-06 18:25     ` Eliezer Tamir
2013-08-07 20:05       ` Ben Hutchings
2013-08-07 20:23         ` Eric Dumazet
2013-08-07 23:41           ` David Miller
2013-08-06 20:39   ` Or Gerlitz
2013-08-06 21:02     ` Eric Dumazet
2013-08-06 12:15 ` Amir Vadai

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=20130806180806.GA8993@sbohrermbp13-local.rgmadvisors.com \
    --to=sbohrer@rgmadvisors.com \
    --cc=amirv@mellanox.com \
    --cc=eliezer.tamir@linux.intel.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).