> On 13 Jun 2019, at 22:25, Doug Ledford wrote:
>
> On Thu, 2019-06-13 at 18:58 +0200, Håkon Bugge wrote:
>>> On 13 Jun 2019, at 16:25, Doug Ledford wrote:
>>>
>>> On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote:
During certain workloads, the default CM response timeout is too
On Thu, Jun 13, 2019 at 07:39:24PM +0200, Håkon Bugge wrote:
>
>
> > On 13 Jun 2019, at 19:23, Jason Gunthorpe wrote:
> >
> > On Thu, Jun 13, 2019 at 06:58:30PM +0200, Håkon Bugge wrote:
> >
> >> If you refer to the backlog parameter in rdma_listen(), I cannot see
> >> it being used at all
On Thu, 2019-06-13 at 18:58 +0200, Håkon Bugge wrote:
> > On 13 Jun 2019, at 16:25, Doug Ledford wrote:
> >
> > On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote:
> > > During certain workloads, the default CM response timeout is too
> > > short, leading to excessive retries. Hence, make it
> On 13 Jun 2019, at 16:25, Doug Ledford wrote:
>
> On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote:
>> During certain workloads, the default CM response timeout is too
>> short, leading to excessive retries. Hence, make it configurable
>> through sysctl. While at it, also make number of
> On 13 Jun 2019, at 19:23, Jason Gunthorpe wrote:
>
> On Thu, Jun 13, 2019 at 06:58:30PM +0200, Håkon Bugge wrote:
>
>> If you refer to the backlog parameter in rdma_listen(), I cannot see
>> it being used at all for IB.
>>
>> For CX-3, which is paravirtualized wrt. MAD packets, it is the
On Thu, Jun 13, 2019 at 06:58:30PM +0200, Håkon Bugge wrote:
> If you refer to the backlog parameter in rdma_listen(), I cannot see
> it being used at all for IB.
>
> For CX-3, which is paravirtualized wrt. MAD packets, it is the proxy
> UD receive queue length for the PF driver that can be
On Thu, 2019-06-13 at 08:28 -0700, Bart Van Assche wrote:
> On 6/13/19 7:25 AM, Doug Ledford wrote:
> > So, to revive this patch, what I'd like to see is some attempt to
> > actually quantify a reasonable timeout for the default backlog
> > depth,
> > then the patch should actually change the
On 6/13/19 7:25 AM, Doug Ledford wrote:
So, to revive this patch, what I'd like to see is some attempt to
actually quantify a reasonable timeout for the default backlog depth,
then the patch should actually change the default to that reasonable
timeout, and then put in the ability to adjust the
On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote:
> During certain workloads, the default CM response timeout is too
> short, leading to excessive retries. Hence, make it configurable
> through sysctl. While at it, also make number of CM retries
> configurable.
>
> The defaults are not
During certain workloads, the default CM response timeout is too
short, leading to excessive retries. Hence, make it configurable
through sysctl. While at it, also make number of CM retries
configurable.
The defaults are not changed.
Signed-off-by: Håkon Bugge
---
v1 -> v2:
* Added
10 matches
Mail list logo
