From: Eliezer Tamir <eliezer.tamir@linux.intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David 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,
Willem de Bruijn <willemb@google.com>,
Ben Hutchings <bhutchings@solarflare.com>,
Andi Kleen <andi@firstfloor.org>, HPA <hpa@zytor.com>,
Eilon Greenstien <eilong@broadcom.com>,
Or Gerlitz <or.gerlitz@gmail.com>,
Amir Vadai <amirv@mellanox.com>,
Alex Rosenbaum <alexr@mellanox.com>,
Avner Ben Hanoch <avnerb@mellanox.com>,
Or Kehati <ork@mellanox.com>,
sockperf-dev@googlegroups.com,
Eliezer Tamir <eliezer@tamir.org.il>
Subject: Re: [PATCH v2 net-next] net: poll/select low latency socket support
Date: Tue, 18 Jun 2013 13:37:18 +0300 [thread overview]
Message-ID: <51C0385E.8030403@linux.intel.com> (raw)
In-Reply-To: <1371551139.3252.249.camel@edumazet-glaptop>
On 18/06/2013 13:25, Eric Dumazet wrote:
> On Tue, 2013-06-18 at 11:58 +0300, Eliezer Tamir wrote:
>> @@ -393,6 +394,15 @@ static inline void wait_key_set(poll_table *wait, unsigned long in,
>> wait->_key |= POLLOUT_SET;
>> }
>>
>> +static inline void wait_key_set_lls(poll_table *wait, bool set)
>> +{
>> + if (set)
>> + wait->_key |= POLL_LL;
>> + else
>> + wait->_key &= ~POLL_LL;
>> +}
>> +
>
> Instead of "bool set" you could use "unsigned int lls_bit"
>
> and avoid conditional :
>
> wait->_key |= lls_bit;
>
> (you do not need to clear the bit in wait->_key, its already cleared in
> wait_key_set())
>
> Alternatively, add a parameter to wait_key_set(), it will be cleaner
OK
>> @@ -486,6 +504,11 @@ int do_select(int n, fd_set_bits *fds, struct timespec *end_time)
>> break;
>> }
>>
>> + if (can_poll_ll(ll_time) && can_ll) {
>
> reorder tests to avoid sched_clock() call :
>
> if (can_ll && can_poll_ll(ll_time))
>
right
>> -static inline unsigned int do_pollfd(struct pollfd *pollfd, poll_table *pwait)
>> +static inline unsigned int do_pollfd(struct pollfd *pollfd, poll_table *pwait,
>> + bool *can_ll, bool try_ll)
>> {
>> unsigned int mask;
>> int fd;
>> @@ -731,7 +755,11 @@ static inline unsigned int do_pollfd(struct pollfd *pollfd, poll_table *pwait)
>> mask = DEFAULT_POLLMASK;
>> if (f.file->f_op && f.file->f_op->poll) {
>> pwait->_key = pollfd->events|POLLERR|POLLHUP;
>> + if (try_ll)
>> + pwait->_key |= POLL_LL;
>
> Well, why enforce POLL_LL ?
>
> Sure we do this for select() as the API doesn't allow us to add the LL
> flag, but poll() can do that.
>
> An application might set POLL_LL flag only on selected fds.
>
> I understand you want nice benchmarks for existing applications,
> but I still think that globally enable/disable LLS for the whole host
> is not a good thing.
>
> POLL_LL wont be a win once we are over committing cpus (too many sockets
> to poll)
I did not intend POLL_LL to be a user visible flag.
But maybe your way will work better.
Do you think we should also report POLL_LL to the user, so it will know
if there are currently ll capable sockets?
That might be hard to do without breaking the flag semantics,
Since we might not want to wake up the user just to report that.
Also, any suggestion on how not to depend on the global sysctl value for
poll? (we can't use a socket option here)
-Eliezer
next prev parent reply other threads:[~2013-06-18 10:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 8:57 [PATCH v2 net-next 0/1] net: lls select poll support Eliezer Tamir
2013-06-18 8:58 ` [PATCH v2 net-next] net: poll/select low latency socket support Eliezer Tamir
2013-06-18 9:08 ` Eric Dumazet
2013-06-18 9:12 ` Eliezer Tamir
2013-06-18 10:25 ` Eric Dumazet
2013-06-18 10:37 ` Eliezer Tamir [this message]
2013-06-18 13:25 ` Eliezer Tamir
2013-06-18 14:35 ` Eric Dumazet
2013-06-18 14:45 ` Eliezer Tamir
2013-06-18 14:50 ` 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=51C0385E.8030403@linux.intel.com \
--to=eliezer.tamir@linux.intel.com \
--cc=alexr@mellanox.com \
--cc=amirv@mellanox.com \
--cc=andi@firstfloor.org \
--cc=avnerb@mellanox.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=donald.c.skidmore@intel.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=eilong@broadcom.com \
--cc=eliezer@tamir.org.il \
--cc=eric.dumazet@gmail.com \
--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 \
--cc=ork@mellanox.com \
--cc=sockperf-dev@googlegroups.com \
--cc=willemb@google.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 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).