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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Feb 2022 14:45:08 +0000 From: Parav Pandit <parav@...dia.com> To: Saeed Mahameed <saeedm@...dia.com> CC: Jakub Kicinski <kuba@...nel.org>, Saeed Mahameed <saeed@...nel.org>, Sunil Sudhakar Rani <sunrani@...dia.com>, Jiri Pirko <jiri@...dia.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "davem@...emloft.net" <davem@...emloft.net>, Bodong Wang <bodong@...dia.com> Subject: RE: [PATCH net-next 1/2] devlink: Add support to set port function as trusted > From: Saeed Mahameed <saeedm@...dia.com> > Sent: Friday, February 4, 2022 12:47 AM > > On 03 Feb 18:35, Parav Pandit wrote: > >Hi Jakub, Saeed, > > > >> From: Saeed Mahameed <saeedm@...dia.com> > >> Sent: Thursday, January 20, 2022 6:11 AM > > > >> >And _right_ amount of X bytes specific for sw_steering was not very clear. > >> >Hence the on/off resource knob looked more doable and abtract. > >> > > >> >I do agree you and Saeed that instead of port function param, port > >> >function > >> resource is more suitable here even though its bool. > >> > > >> > >> I believe flexibility can be achieved with some FW message? Parav can > >> you investigate ? To be clear here the knob must be specific to > >> sw_steering exposed as memory resource. > >> > >I investigated this further with hw and fw teams. > >The memory resource allocator doesn't understand the resource type for page > allocation. > >And even if somehow it is extended, when the pages are freed, they are > returned to the common pool cache instead of returning immediately to the > driver. We will miss the efficiency gained with the caching and reusing these > pages for other functions and for other resource types too. > >This cache efficiency is far more important for speed of resource allocation. > > > >And additionally, it is after all boolean feature to enable/disable a > functionality. > >So I suggest, how about we do something like below? > >It is similar to ethtool -k option, but applicable at the HV PF side to > enable/disable a feature for the functions. > > > >$ devlink port function feature set ptp/ipsec/tlsoffload on/off $ > >devlink port function feature set device_specific_feature1 on/off > > > >$ devlink port show > >pci/0000:06:00.0/1: type eth netdev eth0 flavour pcivf pfnum 0 vfnum 0 > > function: > > hw_addr 00:00:00:00:00:00 > > feature: > > tlsoffload <on/off> > > ipsec <on/off> > > ptp <on/off> > > device_specific_feature1 <on/off> > > > > Given the HW limitation of differentiating between memory allocated for > different resources, and after a second though about the fact that most of > ConnectX resources are mapped to ICM memory which is managed by FW, > although it would've been very useful to manager resources this way, such > architecture is very specific to ConnectX and might not suite other vendors, so > explicit API as the above sounds like a better compromise, but I would put > device_specific_feature(s) into a separate category/list > > basically you are looking for: > > 1) ethtool -k equivalent for devlink > 2) ethtool --show-priv-flags equivalent for devlink > > I think that's reasonable. > Right. I was thinking to put under single "feature" bucket like above. Shall we proceed with this UAPI? > >This enables having well defined features per function and odd device specific > feature. > >It also doesn't overload the device on doing accounting pages for boolean > functionality. > >Does it look reasonable?
Powered by blists - more mailing lists