netdev - Re: Driver profiles RFC

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Aug 2017 07:34:41 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Arkadi Sharshevsky <arkadis@...lanox.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>, ivecera@...hat.com,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        John Fastabend <john.fastabend@...il.com>,
        Andrew Lunn <andrew@...n.ch>, Jiri Pirko <jiri@...nulli.us>,
        mlxsw <mlxsw@...lanox.com>
Subject: Re: Driver profiles RFC

On Wed, Aug 9, 2017 at 4:43 AM, Arkadi Sharshevsky <arkadis@...lanox.com> wrote:
>
>
> On 08/08/2017 07:08 PM, Roopa Prabhu wrote:
>> On Tue, Aug 8, 2017 at 6:15 AM, Arkadi Sharshevsky <arkadis@...lanox.com> wrote:
>>>

[snip]

>>> User Configuration
>>> ------------------
>>> Such an UAPI is very low level, and thus an average user may not know how to
>>> adjust this sizes according to his needs. The vendor can provide several
>>> tested configuration files that the user can choose from. Each config file
>>> will be measured in terms of: MAC addresses, L3 Neighbors (IPv4, IPv6),
>>> LPM entries (IPv4,IPv6) in order to provide approximate results. By this an
>>> average user will choose one of the provided ones. Furthermore, a more
>>> advanced user could play with the numbers for his personal benefit.
>>>
>>> Reference
>>> =========
>>> [1] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnetdevconf.org%2F2.1%2Fpapers%2Fdpipe_netdev_2_1.odt&data=02%7C01%7Carkadis%40mellanox.com%7Cc64b0d54e3e94d07b64c08d4de77bf8b%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378053281241266&sdata=9u%2BFwGF%2FjkmNogPF7Cm%2FfwJsaPVkr%2BC3%2F8x1IVbszRg%3D&reserved=0
>>>
>>
>> Thanks for sending this out. There is very much a need for this.
>> and agree, user-space app config can translate to what values they want and
>>  kernel api can be a low level api.
>>
>> But how about we align these resource limits with the kernel resource limits ?
>> For example we usually map l3 hw neighbor limits to kernel software gc_thresh
>> values (which are configurable via sysctl). This is one way to give
>> user immediate
>> feedback on resource full errors. It would be nice if we can introduce
>> limits for routes and
>> mac addresses. Defaults could be what they are today but user
>> configurable ...like I said,
>> neighbor subsystem already allows this.
>>
>
> Hi Roopa, thanks for the feedback.
>
> Regarding aligning the hardware tables sizes with the kernel software
> limits. The hardware resources (internal memory) are much more limited
> than the software one. Please consider the following scenario:
>
> 1. User adds limit to neighbor table (as you suggested), which uses the
>    hash memory portion.
> 2. User adds many routes, the routes uses the hash memory resource as well,
>    potentially.
> 3. The kernel adds some neighbors dynamically, the neighbor offloading
>    fails due to lack of this shared resource, the user get confused because
>    its lower then what he configured in 1).
>
> Thus providing max size on specific table is not well defined due to
> limited
> shared resource. Thus, the feedback the user gets can be not very accurate.
> Furthermore, guessing the resource partitioning based only on the subset of
> tables which use it makes me little bit uncomfortable.

yep, understood. I am aware of  some of these problems as well.

>
> The proposed API aims at solving this issue by providing abstraction for
> this hw behavior, and provide the connection with the hardware table, thus
> providing more accurate and well defined description of the system.
>
> I totally agree that this API should be enhanced in order provide the
> occupancy of the this 'resource'. For example, the user first observe the
> tables and sees the resource<->table mapping, then see the resource
> occupancy:
>
> #devlink dpipe resource occupancy pci/0000:03:00.0 Mem
>
> By this the user can understand the offloading limitation, and maybe figure
> out that he should change the partitioning.
>

yes, sounds good.