On 29/05/2013 21:52, Or Gerlitz wrote:
Eliezer Tamir wrote:
Or Gerlitz wrote:
Unlike with TCP sockets, UDP sockets may receive packets from multiple
sources and hence the receiving context may be steered to be executed
on different cores through RSS or other Flow-Steering HW mechanisms
which
On 29/05/2013 22:08, Eric Dumazet wrote:
On Wed, 2013-05-29 at 21:52 +0300, Or Gerlitz wrote:
Eliezer Tamir wrote:
Or Gerlitz wrote:
Unlike with TCP sockets, UDP sockets may receive packets from multiple
sources and hence the receiving context may be steered to be executed
on different core
On Wed, 2013-05-29 at 17:14 +0300, Or Gerlitz wrote:
> On Wed, May 29, 2013 at 9:39 AM, Eliezer Tamir
> wrote:
> > Adds a new ndo_ll_poll method and the code that supports and uses it.
> > This method can be used by low latency applications to busy poll Ethernet
> > device queues directly from the
On Wed, 2013-05-29 at 21:52 +0300, Or Gerlitz wrote:
> Eliezer Tamir wrote:
> > Or Gerlitz wrote:
>
> >> Unlike with TCP sockets, UDP sockets may receive packets from multiple
> >> sources and hence the receiving context may be steered to be executed
> >> on different cores through RSS or other F
Eliezer Tamir wrote:
> Or Gerlitz wrote:
>> Unlike with TCP sockets, UDP sockets may receive packets from multiple
>> sources and hence the receiving context may be steered to be executed
>> on different cores through RSS or other Flow-Steering HW mechanisms
>> which could mean different napi con
On 29/05/2013 17:20, yaniv saar wrote:
Hi Eliezer,
(If I'm too late then a future note...)
Why make polling a system-wide configuration?
Wouldn't it make more sense to implement a sock option?
An even better solution might be aggregation/combination of both types of
configurations.
-- Yaniv Sa'
On 29/05/2013 17:14, Or Gerlitz wrote:
On Wed, May 29, 2013 at 9:39 AM, Eliezer Tamir
wrote:
Adds a new ndo_ll_poll method and the code that supports and uses it.
This method can be used by low latency applications to busy poll Ethernet
device queues directly from the socket code. The value of
Hi Eliezer,
(If I'm too late then a future note...)
Why make polling a system-wide configuration?
Wouldn't it make more sense to implement a sock option?
An even better solution might be aggregation/combination of both types
of configurations.
-- Yaniv Sa'ar
On Wed, May 29, 2013 at 5:14 PM, Or
On Wed, May 29, 2013 at 9:39 AM, Eliezer Tamir
wrote:
> Adds a new ndo_ll_poll method and the code that supports and uses it.
> This method can be used by low latency applications to busy poll Ethernet
> device queues directly from the socket code. The value of sysctl_net_ll_poll
> controls how ma
On 29/05/2013 16:37, Eric Dumazet wrote:
On Wed, 2013-05-29 at 09:39 +0300, Eliezer Tamir wrote:
+static inline unsigned long ll_end_time(void)
+{
+ return TSC_MHZ * ACCESS_ONCE(sysctl_net_ll_poll) + get_cycles();
+}
This can overflow.
Multiply is giving 32bits, as tsc_khz is an int,
On Wed, 2013-05-29 at 14:42 +0100, David Laight wrote:
> > > +/* we don't mind a ~2.5% imprecision */
> > > +#define TSC_MHZ (tsc_khz >> 10)
>
> Wouldn't (tsc_khz << 10) be better?
We want number of cycles per usec.
Your formula gives number of cycles per 1.024 second.
--
To unsubscribe from t
> > +/* we don't mind a ~2.5% imprecision */
> > +#define TSC_MHZ (tsc_khz >> 10)
Wouldn't (tsc_khz << 10) be better?
David
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
On Wed, 2013-05-29 at 09:39 +0300, Eliezer Tamir wrote:
> +/* we don't mind a ~2.5% imprecision */
> +#define TSC_MHZ (tsc_khz >> 10)
> +
> +static inline unsigned long ll_end_time(void)
> +{
> + return TSC_MHZ * ACCESS_ONCE(sysctl_net_ll_poll) + get_cycles();
> +}static inline unsigned long l
13 matches
Mail list logo
