All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemb@google.com>
To: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Cc: Or Gerlitz <or.gerlitz@gmail.com>,
	Dave Miller <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Don Skidmore <donald.c.skidmore@intel.com>,
	e1000-devel@lists.sourceforge.net,
	Andi Kleen <andi@firstfloor.org>, HPA <hpa@zytor.com>,
	Eliezer Tamir <eliezer@tamir.org.il>
Subject: Re: [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll
Date: Tue, 21 May 2013 10:19:39 -0400	[thread overview]
Message-ID: <CA+FuTSeYQs7yhGbm_BGoQQbzSG77mEXdPccFubWb04UoMoE6nA@mail.gmail.com> (raw)
In-Reply-To: <519B1A2B.4010909@linux.intel.com>

On Tue, May 21, 2013 at 2:54 AM, Eliezer Tamir
<eliezer.tamir@linux.intel.com> wrote:
> On 20/05/2013 23:20, Or Gerlitz wrote:
>>
>> On Mon, May 20, 2013 at 1:16 PM, Eliezer Tamir
>> <eliezer.tamir@linux.intel.com> wrote:
>>>
>>> Add the ixgbe driver code implementing ndo_ll_poll.
>>> It should be easy for other drivers to do something similar
>>> in order to enable support for CONFIG_INET_LL_RX_POLL
>>
>>
>> I am not sure,
>
>
> Willem ported this to <some undisclosed HW that they use at Google>, his
> feedback was that it was not a major effort.

The core ndo_ll_poll implementation is generally a subset of a device
driver's existing napi callback. It cleans the queues, but it skips
napi_complete and unmasking of the IRQ.

+       ixgbe_for_each_ring(ring, q_vector->rx) {
+               found = ixgbe_clean_rx_irq(q_vector, ring, 4);
+               if (found)
+                       break;
+       }

A subtle difference in the above code vs ixgbe_poll is that the
callback returns as soon as some data arrived on a queue, as opposed
to iterating over all queues. The budget is lower, too. Since not all
data arriving is necessarily destined towards polling socket, this may
or may not be an improvement.

Besides that, the driver has to mark the packet with
ll_mark_skb(&cq->napi, skb);

On devices where tx completion interrupts share the same IRQ as rx
interrupts, the driver may also have to clean the tx queue once in a
while (at obvious tail latency cost). LLS does not disable the IRQ,
but I think the suggestion was to set its moderation threshold very
high to avoid net_rx_action/LLS lock contention. If so, starvation may
occur.

The most difficult bit is handling mutual exclusion with the
interrupt-driven receive path. The ixgbe port has its own internal
locking mechanism in anticipation of future use cases that can be
lock-free. As first approximation, I just took the napi->poll_lock,
similar to how netpoll handles mutual exclusion with net_rx_action.

WARNING: multiple messages have this Message-ID (diff)
From: Willem de Bruijn <willemb@google.com>
To: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Cc: Or Gerlitz <or.gerlitz@gmail.com>,
	e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
	HPA <hpa@zytor.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>,
	Eliezer Tamir <eliezer@tamir.org.il>,
	Dave Miller <davem@davemloft.net>
Subject: Re: [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll
Date: Tue, 21 May 2013 10:19:39 -0400	[thread overview]
Message-ID: <CA+FuTSeYQs7yhGbm_BGoQQbzSG77mEXdPccFubWb04UoMoE6nA@mail.gmail.com> (raw)
In-Reply-To: <519B1A2B.4010909@linux.intel.com>

On Tue, May 21, 2013 at 2:54 AM, Eliezer Tamir
<eliezer.tamir@linux.intel.com> wrote:
> On 20/05/2013 23:20, Or Gerlitz wrote:
>>
>> On Mon, May 20, 2013 at 1:16 PM, Eliezer Tamir
>> <eliezer.tamir@linux.intel.com> wrote:
>>>
>>> Add the ixgbe driver code implementing ndo_ll_poll.
>>> It should be easy for other drivers to do something similar
>>> in order to enable support for CONFIG_INET_LL_RX_POLL
>>
>>
>> I am not sure,
>
>
> Willem ported this to <some undisclosed HW that they use at Google>, his
> feedback was that it was not a major effort.

The core ndo_ll_poll implementation is generally a subset of a device
driver's existing napi callback. It cleans the queues, but it skips
napi_complete and unmasking of the IRQ.

+       ixgbe_for_each_ring(ring, q_vector->rx) {
+               found = ixgbe_clean_rx_irq(q_vector, ring, 4);
+               if (found)
+                       break;
+       }

A subtle difference in the above code vs ixgbe_poll is that the
callback returns as soon as some data arrived on a queue, as opposed
to iterating over all queues. The budget is lower, too. Since not all
data arriving is necessarily destined towards polling socket, this may
or may not be an improvement.

Besides that, the driver has to mark the packet with
ll_mark_skb(&cq->napi, skb);

On devices where tx completion interrupts share the same IRQ as rx
interrupts, the driver may also have to clean the tx queue once in a
while (at obvious tail latency cost). LLS does not disable the IRQ,
but I think the suggestion was to set its moderation threshold very
high to avoid net_rx_action/LLS lock contention. If so, starvation may
occur.

The most difficult bit is handling mutual exclusion with the
interrupt-driven receive path. The ixgbe port has its own internal
locking mechanism in anticipation of future use cases that can be
lock-free. As first approximation, I just took the napi->poll_lock,
similar to how netpoll handles mutual exclusion with net_rx_action.

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

  parent reply	other threads:[~2013-05-21 14:20 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20 10:15 [PATCH v3 net-next 0/4] net: low latency Ethernet device polling Eliezer Tamir
2013-05-20 10:15 ` Eliezer Tamir
2013-05-20 10:16 ` [PATCH v3 net-next 1/4] net: implement support for low latency socket polling Eliezer Tamir
2013-05-20 10:16   ` Eliezer Tamir
2013-05-20 15:29   ` Eric Dumazet
2013-05-20 19:40     ` David Miller
2013-05-21  7:28     ` Eliezer Tamir
2013-05-21 13:28       ` Eric Dumazet
2013-05-21 17:02         ` Pekka Riikonen
2013-05-21 17:48           ` Eric Dumazet
2013-05-21 17:51             ` Eric Dumazet
2013-05-21 17:51               ` Eric Dumazet
2013-05-21 19:25               ` Eliezer Tamir
2013-05-21 19:25                 ` Eliezer Tamir
2013-05-21 19:29                 ` Eric Dumazet
2013-05-21 19:29                   ` Eric Dumazet
2013-05-21 18:49           ` David Miller
2013-05-21 19:31             ` Pekka Riikonen
2013-05-21 19:31               ` Pekka Riikonen
2013-05-20 10:16 ` [PATCH v3 net-next 2/4] tcp: add TCP support for low latency receive poll Eliezer Tamir
2013-05-20 10:16   ` Eliezer Tamir
2013-05-20 13:49   ` Eric Dumazet
2013-05-20 14:59     ` Eliezer Tamir
2013-05-20 14:59       ` Eliezer Tamir
2013-05-20 10:16 ` [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll Eliezer Tamir
2013-05-20 10:16   ` Eliezer Tamir
2013-05-20 20:20   ` Or Gerlitz
2013-05-20 20:20     ` Or Gerlitz
2013-05-20 20:33     ` Andi Kleen
2013-05-20 20:42       ` Or Gerlitz
2013-05-20 21:01         ` Andi Kleen
2013-05-21  6:23           ` Or Gerlitz
2013-05-21  6:23             ` Or Gerlitz
2013-05-21  6:54     ` Eliezer Tamir
2013-05-21  6:54       ` Eliezer Tamir
2013-05-21  7:06       ` Eilon Greenstein
2013-05-21  7:06         ` Eilon Greenstein
2013-05-21  7:14         ` David Miller
2013-05-21  8:24           ` Or Gerlitz
2013-05-21  8:24             ` Or Gerlitz
2013-05-21  8:31             ` Eliezer Tamir
2013-05-21  8:31               ` Eliezer Tamir
2013-05-21  8:39             ` David Miller
2013-05-21  8:42               ` Eliezer Tamir
2013-05-21  8:42                 ` Eliezer Tamir
2013-05-21  8:43               ` Or Gerlitz
2013-05-21  8:43                 ` Or Gerlitz
2013-05-21 10:27                 ` Eliezer Tamir
2013-05-21 10:41                   ` Or Gerlitz
2013-05-21  8:21         ` Or Gerlitz
2013-05-21  8:21           ` Or Gerlitz
2013-05-21  8:28           ` Eilon Greenstein
2013-05-21  8:28             ` Eilon Greenstein
2013-05-21 14:19       ` Willem de Bruijn [this message]
2013-05-21 14:19         ` Willem de Bruijn
2013-05-20 10:16 ` [PATCH v3 net-next 4/4] ixgbe: add extra stats " Eliezer Tamir
2013-05-20 10:16   ` Eliezer Tamir
2013-05-21 12:06 ` [PATCH v3 net-next 0/4] net: low latency Ethernet device polling Alex Rosenbaum
2013-05-21 12:29   ` Eliezer Tamir
2013-05-21 13:15     ` Alex Rosenbaum
2013-05-21 13:15       ` Alex Rosenbaum
2013-05-21 13:31       ` Eric Dumazet
2013-05-23 11:06       ` Eliezer Tamir
2013-05-23 11:45         ` Alex Rosenbaum
2013-05-21 14:30     ` Willem de Bruijn
2013-05-21 14:30       ` Willem de Bruijn
2013-05-21 18:15     ` Ben Hutchings
2013-05-21 18:15       ` Ben Hutchings
2013-05-22  9:35       ` Eliezer Tamir

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=CA+FuTSeYQs7yhGbm_BGoQQbzSG77mEXdPccFubWb04UoMoE6nA@mail.gmail.com \
    --to=willemb@google.com \
    --cc=andi@firstfloor.org \
    --cc=davem@davemloft.net \
    --cc=donald.c.skidmore@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=eliezer.tamir@linux.intel.com \
    --cc=eliezer@tamir.org.il \
    --cc=hpa@zytor.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=or.gerlitz@gmail.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.