netdev - Re: [RFC net-next v2 5/5] net:openvswitch: add psample support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1e009e95-e6b2-4db6-9d92-dd830640289d@redhat.com>
Date: Wed, 10 Apr 2024 15:44:49 +0200
From: Adrian Moreno <amorenoz@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Ilya Maximets <i.maximets@....org>
Cc: netdev@...r.kernel.org, jiri@...nulli.us, xiyou.wangcong@...il.com,
 cmi@...dia.com, yotam.gi@...il.com, aconole@...hat.com, echaudro@...hat.com,
 horms@...nel.org
Subject: Re: [RFC net-next v2 5/5] net:openvswitch: add psample support



On 4/9/24 23:49, Jakub Kicinski wrote:
> On Tue, 9 Apr 2024 11:35:04 +0200 Ilya Maximets wrote:
>>> If we try to implement all our actions following this way, and we keep just
>>> copying the incoming actions into the internal representation, we incur in
>>> unnecessary memory overhead (e.g: storing 2x struct nlaattr + padding of extra
>>> memory to store 2 integers).
>>>
>>> I don't want to derail the discussion into historical or futuristic changes,
>>> just saying that the approach taken in the SAMPLE action (not including this
>>> patch) of exposing arguments as attributes but having a kernel-only struct to
>>> store them seems to me a good compromise.
>>
>> Sure.  As I said, it's fine to have internal structures.  My comment
>> was mainly about uAPI part.  We should avoid structures in uAPI if
>> possible, as they are very hard to maintain and keep compatible with
>> older userspace in case some changes will be needed in the future.
> 
> FWIW there are some YAML specs for ovs under
> Documentation/netlink/specs/ovs_*
> perhaps they should also be updated?
> 

Sure, I will update them in the next version.
Thanks.