On Wed, Aug 9, 2017 at 4:43 AM, Arkadi Sharshevsky <arka...@mellanox.com> wrote: > > > On 08/08/2017 07:08 PM, Roopa Prabhu wrote: >> On Tue, Aug 8, 2017 at 6:15 AM, Arkadi Sharshevsky <arka...@mellanox.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.
