Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1603003
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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