Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a438e076-7fa1-1b1c-0e39-597b57c39367@nbd.name>
Date:   Sun, 17 Jul 2022 07:02:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.11.0
Subject: Re: [PATCH 0/3] Mesh Fast xmit support
Content-Language: en-US
To:     "Sriram R (QUIC)" <quic_srirrama@quicinc.com>,
        Johannes Berg <johannes@sipsolutions.net>
Cc:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
References: <1654857639-12346-1-git-send-email-quic_srirrama@quicinc.com>
 <98e3a2743ab770fbd3f14dca14b62105c8457bf6.camel@sipsolutions.net>
 <SN6PR02MB4334670B5FD85EB6940A64F8F7BD9@SN6PR02MB4334.namprd02.prod.outlook.com>
 <9bce16843dcc698740d90d8963a1a55516fb1d39.camel@sipsolutions.net>
 <SN6PR02MB4334F77368A1AC3F1202117CF7BD9@SN6PR02MB4334.namprd02.prod.outlook.com>
 <940aa2fe0f2497e9fab9a5118001034b5de18d64.camel@sipsolutions.net>
 <19477e0584f7031b37fcdfcc5ef10e7b00842f07.camel@sipsolutions.net>
 <SN6PR02MB433432544D1F5FF9672579C3F78B9@SN6PR02MB4334.namprd02.prod.outlook.com>
From:   Felix Fietkau <nbd@nbd.name>
In-Reply-To: <SN6PR02MB433432544D1F5FF9672579C3F78B9@SN6PR02MB4334.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 15.07.22 04:16, Sriram R (QUIC) wrote:
>>-----Original Message-----
>>From: Johannes Berg <johannes@sipsolutions.net>
>>Sent: Friday, July 1, 2022 3:30 PM
>>To: Sriram R (QUIC) <quic_srirrama@quicinc.com>; nbd@nbd.name
>>Cc: linux-wireless@vger.kernel.org
>>Subject: Re: [PATCH 0/3] Mesh Fast xmit support
>>
>>WARNING: This email originated from outside of Qualcomm. Please be wary of
>>any links or attachments, and do not enable macros.
>>
>>On Fri, 2022-07-01 at 11:59 +0200, Johannes Berg wrote:
>>>
>>> >   So was skeptical on having a higher cache size(like 250 or 500 max).
>>> > Hence had a value of 50 and left the configuration part for devices
>>> > which needed higher cache.
>>> > But as you mentioned, this is only runtime max memory and not default.
>>> >  So we should be fine to set some high limit, If above is not a
>>> > concern could we stick to an upper limit of ~150-200 ?
>>>
>>> Right, I'm fine with that. I was just throwing out 500 as a random
>>> number to show that it's not really a huge memory requirement.
>>>
>>
>>But maybe Felix wants to comment? Felix?
> Hi Felix,
> 
>    Could you kindly share your comments on this.
I agree with making it big enough so that almost nobody has to tune it. 
I think 512 would be a reasonable default.
By the way, if I'm counting correctly, you might be able to reduce the 
size of the cache entries a bit by moving the 'key' field below the 
'band' field, getting rid of some padding.

- Felix