Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1603003

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

From Eric Dumazet <eric.dumazet@gmail.com>
Newsgroups linux.kernel
Subject Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths
Date 2017-03-17 04:00 +0100
Message-ID <tlQhs-7K9-9@gated-at.bofh.it> (permalink)
References (1 earlier) <tlItB-2iT-27@gated-at.bofh.it> <tlLKN-4LF-5@gated-at.bofh.it> <tlMnw-51X-17@gated-at.bofh.it> <tlMxb-56x-5@gated-at.bofh.it> <tlQ7L-7Ds-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:

> I don't know.  My concern here is about the cost of going through all
> that code just for something that we know shouldn't be valid.  If
> nothing else I might update sk_can_busy_loop so that it doesn't try
> busy looping on a sk_napi_id that is NR_CPU or less.

But why would that be a win ?

if napi_by_id() returns NULL, we immediately give up, (goto out;)

So why should we add a code that will add something that will not be
useful for the vast majority of the cases where the ID is valid and we
need to do the hash look up ?

Is libc trying to avoid doing syscalls like close(-1) ?

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[net-next PATCH 0/5] Add busy poll support for epoll under certain  circumstances Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-16 19:40 +0100
  [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in  socket receive paths Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-16 19:40 +0100
    Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id  in socket receive paths Eric Dumazet <eric.dumazet@gmail.com> - 2017-03-16 23:10 +0100
      Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in  socket receive paths Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-16 23:50 +0100
        Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id  in socket receive paths Eric Dumazet <eric.dumazet@gmail.com> - 2017-03-17 00:00 +0100
          Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in  socket receive paths Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-17 03:50 +0100
            Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id  in socket receive paths Eric Dumazet <eric.dumazet@gmail.com> - 2017-03-17 04:00 +0100
            Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in  socket receive paths Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-17 04:00 +0100
            Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id  in socket receive paths Eric Dumazet <eric.dumazet@gmail.com> - 2017-03-17 04:10 +0100
      Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id  in socket receive paths "Samudrala, Sridhar" <sridhar.samudrala@intel.com> - 2017-03-16 23:50 +0100
  [net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK receive  path Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-16 19:40 +0100
    Re: [net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK  receive path Eric Dumazet <eric.dumazet@gmail.com> - 2017-03-16 23:10 +0100
      Re: [net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK  receive path Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-16 23:40 +0100
  [net-next PATCH 3/5] net: Introduce SO_INCOMING_NAPI_ID Alexander Duyck <alexander.duyck@gmail.com> - 2017-03-16 19:40 +0100
    Re: [net-next PATCH 3/5] net: Introduce SO_INCOMING_NAPI_ID Eric Dumazet <eric.dumazet@gmail.com> - 2017-03-17 00:00 +0100
  Re: [net-next PATCH 0/5] Add busy poll support for epoll under  certain circumstances Michael Kerrisk <mtk.manpages@gmail.com> - 2017-03-18 12:50 +0100

csiph-web