All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
	Alexander Duyck <alexander.duyck@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	edumazet@google.com, davem@davemloft.net
Subject: Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths
Date: Thu, 16 Mar 2017 15:41:03 -0700	[thread overview]
Message-ID: <58CB147F.7080401@intel.com> (raw)
In-Reply-To: <1489701936.28631.249.camel@edumazet-glaptop3.roam.corp.google.com>


On 3/16/2017 3:05 PM, Eric Dumazet wrote:
> On Thu, 2017-03-16 at 11:32 -0700, Alexander Duyck wrote:
>> From: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>
>> Fix sk_mark_napi_id() and sk_mark_napi_id_once() to set sk_napi_id only if
>> skb->napi_id is a valid value.
>>
>> This happens in loopback paths where skb->napi_id is not updated in
>> rx path and holds sender_cpu that is set in xmit path.
>>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> ---
>>   include/net/busy_poll.h |    5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
>> index c0452de83086..67991635953e 100644
>> --- a/include/net/busy_poll.h
>> +++ b/include/net/busy_poll.h
>> @@ -116,7 +116,8 @@ static inline bool sk_busy_loop(struct sock *sk, int nonblock)
>>   static inline void sk_mark_napi_id(struct sock *sk, const struct sk_buff *skb)
>>   {
>>   #ifdef CONFIG_NET_RX_BUSY_POLL
>> -	sk->sk_napi_id = skb->napi_id;
>> +	if (skb->napi_id > (u32)NR_CPUS)
>> +		sk->sk_napi_id = skb->napi_id;
>>   #endif
>>   }
>>   
>> @@ -125,7 +126,7 @@ static inline void sk_mark_napi_id_once(struct sock *sk,
>>   					const struct sk_buff *skb)
>>   {
>>   #ifdef CONFIG_NET_RX_BUSY_POLL
>> -	if (!sk->sk_napi_id)
>> +	if (!sk->sk_napi_id && (skb->napi_id > (u32)NR_CPUS))
>>   		sk->sk_napi_id = skb->napi_id;
>>   #endif
>>   }
>>
> It is not clear why this patch is needed .
>
> What you describe here is the case we might receive packets for a socket
> coming from different interfaces ?

This is seen with AF_UNIX or AF_INET sockets over loopback.
>
> If skb->napi_id is a sender_cpu, why should we prevent overwriting the
> sk_napi_id with it, knowing that busy polling will simply ignore the
> invalid value ?

We are not checking for invalid VALUE(< NR_CPUs) in busy_poll,
Non-zero sk->napi_id is considered valid.

If we don't want to add this check while setting sk->sk_napi_Id, we 
could change the
check in ep_set_busy_poll_napi_id() to check for invalid value rather 
than non-zero value.

>
> Do not get me wrong :
>
> I simply try to understand why the test about napi_id validity is now
> done twice :
>
> 1) At the time we are writing into sk->sk_napi_id
>
> 2) At busy polling time when we read sk->sk_napi_id
>
>
>

  parent reply	other threads:[~2017-03-16 22:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-16 18:32 [net-next PATCH 0/5] Add busy poll support for epoll under certain circumstances Alexander Duyck
2017-03-16 18:32 ` [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths Alexander Duyck
2017-03-16 22:05   ` Eric Dumazet
2017-03-16 22:33     ` Alexander Duyck
2017-03-16 22:50       ` Eric Dumazet
2017-03-17  2:40         ` Alexander Duyck
2017-03-17  2:55           ` Eric Dumazet
2017-03-17  2:57           ` Eric Dumazet
2017-03-17  2:59             ` Alexander Duyck
2017-03-16 22:41     ` Samudrala, Sridhar [this message]
2017-03-16 18:32 ` [net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK receive path Alexander Duyck
2017-03-16 22:04   ` Eric Dumazet
2017-03-16 22:36     ` Alexander Duyck
2017-03-16 18:32 ` [net-next PATCH 3/5] net: Introduce SO_INCOMING_NAPI_ID Alexander Duyck
2017-03-16 22:27   ` Eric Dumazet
2017-03-16 18:32 ` [net-next PATCH 4/5] net: Commonize busy polling code to focus on napi_id instead of socket Alexander Duyck
2017-03-16 18:33 ` [net-next PATCH 5/5] epoll: Add busy poll support to epoll with socket fds Alexander Duyck
2017-03-16 22:11   ` Eric Dumazet
2017-03-16 22:38     ` Alexander Duyck
     [not found] ` <20170316183142.15806.38824.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2017-03-18 11:45   ` [net-next PATCH 0/5] Add busy poll support for epoll under certain circumstances Michael Kerrisk
2017-03-18 11:45     ` Michael Kerrisk

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=58CB147F.7080401@intel.com \
    --to=sridhar.samudrala@intel.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.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 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.