On Sat, Mar 18, 2017 at 7:07 PM, Subash Abhinov Kasiviswanathan
wrote:
>> Less than 1% performance improvement in a benchmark doesn't justify
>> the complexity of the patch. Eric's hypothesis was that an unconnected
>> UDP socket may show issues because of cache misses in
On Sat, 2017-03-18 at 20:07 -0600, Subash Abhinov Kasiviswanathan wrote:
> > Less than 1% performance improvement in a benchmark doesn't justify
> > the complexity of the patch. Eric's hypothesis was that an unconnected
> > UDP socket may show issues because of cache misses in look-ups due to
> >
Less than 1% performance improvement in a benchmark doesn't justify
the complexity of the patch. Eric's hypothesis was that an unconnected
UDP socket may show issues because of cache misses in look-ups due to
so many different sources. This should be fairly easy to benchmark by
randomly setting
On Sat, Mar 18, 2017 at 10:32 AM, Subash Abhinov Kasiviswanathan
wrote:
>> All these hypotheses are quite testable, and it should be obvious that
>> if a patch is supposed to improve performance there should be some
>> effort to quantify the impact.
>
>
> Hi Tom
>
> I ran
All these hypotheses are quite testable, and it should be obvious that
if a patch is supposed to improve performance there should be some
effort to quantify the impact.
Hi Tom
I ran a single stream unconnected UDPv4 test on an ARM64 system and I
see
a slight increase in performance (782 ->
On Fri, Mar 10, 2017 at 4:22 PM, Eric Dumazet wrote:
> On Fri, 2017-03-10 at 08:33 -0800, Tom Herbert wrote:
>
>> Okay, now I'm confused. You're saying that when early demux was added
>> for IPv6 performance improved, but this patch is allowing early demux
>> to be
On Fri, 2017-03-10 at 08:33 -0800, Tom Herbert wrote:
> Okay, now I'm confused. You're saying that when early demux was added
> for IPv6 performance improved, but this patch is allowing early demux
> to be disabled on the basis that it hurts performance for unconnected
> UDP workloads. While it's
On Thu, Mar 9, 2017 at 9:26 PM, Subash Abhinov Kasiviswanathan
wrote:
> On 2017-03-09 20:42, Tom Herbert wrote:
>>
>> On Thu, Mar 9, 2017 at 7:31 PM, Subash Abhinov Kasiviswanathan
>> wrote:
>>>
>>> Certain system process significant unconnected
Hi Subash,
[auto build test ERROR on v4.9-rc8]
[cannot apply to net-next/master net/master next-20170309]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Subash,
[auto build test ERROR on v4.9-rc8]
[cannot apply to net-next/master net/master next-20170309]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Well, then you need to make sure ipprot->early_demux is read once in
the
callers, like ip_rcv_finish(), otherwise compiler could read it twice
and we could deref a NULL pointer.
ipprot = rcu_dereference(inet_protos[protocol]);
if (ipprot && ipprot->early_demux) {
ipprot->early_demux(skb);
On 2017-03-09 20:42, Tom Herbert wrote:
On Thu, Mar 9, 2017 at 7:31 PM, Subash Abhinov Kasiviswanathan
wrote:
Certain system process significant unconnected UDP workload.
It would be preferrable to disable UDP early demux for those systems
and enable it for TCP only.
On Thu, 2017-03-09 at 20:31 -0700, Subash Abhinov Kasiviswanathan wrote:
> Certain system process significant unconnected UDP workload.
> It would be preferrable to disable UDP early demux for those systems
> and enable it for TCP only.
> +void tcp_v4_early_demux_configure(int enable)
> +{
> +
On Thu, Mar 9, 2017 at 7:31 PM, Subash Abhinov Kasiviswanathan
wrote:
> Certain system process significant unconnected UDP workload.
> It would be preferrable to disable UDP early demux for those systems
> and enable it for TCP only.
>
Presumably you want this for
14 matches
Mail list logo