lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171020.131836.933570982545888951.davem@davemloft.net>
Date:   Fri, 20 Oct 2017 13:18:36 +0100 (WEST)
From:   David Miller <davem@...emloft.net>
To:     felix.manlunas@...ium.com
Cc:     netdev@...r.kernel.org, raghu.vatsavayi@...ium.com,
        derek.chickles@...ium.com, satananda.burla@...ium.com
Subject: Re: [PATCH net-next] liquidio: xmit_more support

From: Felix Manlunas <felix.manlunas@...ium.com>
Date: Wed, 18 Oct 2017 10:36:02 -0700

> From: Intiyaz Basha <intiyaz.basha@...ium.com>
> 
> Do not write the Tx doorbell if skb->xmit_more is set unless the Tx
> queue is full or stopped.
> 
> Signed-off-by: Intiyaz Basha <intiyaz.basha@...ium.com>
> Signed-off-by: Derek Chickles <derek.chickles@...ium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@...ium.com>

You're going to need some kind of added heuristic for this.

If the TX queue is idle, and then you get a full TX queue's
worth of xmit_more frames, you do not want to defer the doorbell
until the entire queue has been filled.

But that is what you are doing.

You have to experment with different deferral limit values to
see where latency starts to be negatively impacted.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ