netdev - Re: [PATCH net-next 0/2] ovs: refresh a flow via netlink

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: <CAMEOZh+TR3S+30e+u9yVH04XN2Z26WEnhNK=t7DFq8YaBmjFyA@mail.gmail.com>
Date:	Thu, 17 Mar 2016 17:24:57 +0100
From:	Samuel Gauthier <samuel.gauthier@...nd.com>
To:	Jesse Gross <jesse@...nel.org>
Cc:	Pravin Shelar <pshelar@...ira.com>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	ovs dev <dev@...nvswitch.org>
Subject: Re: [PATCH net-next 0/2] ovs: refresh a flow via netlink

2016-03-17 0:23 GMT+01:00 Jesse Gross <jesse@...nel.org>:
> On Wed, Mar 16, 2016 at 8:07 AM, Samuel Gauthier
> <samuel.gauthier@...nd.com> wrote:
>> This patchset adds a netlink api to refresh an existing flow in
>> openvswitch.
>>
>> When a packet is sent in the openvswitch kernel datapath and no
>> flow is found, the packet is sent to the ovs-vswitchd daemon,
>> which will process the packet, and ask the kernel to create a new
>> flow. The next packets for this flow will be processed by the
>> kernel datapath. If a flow is not used for a (configurable)
>> period of time, ovs-vswitchd removes the flow from the kernel.
>>
>> As a result, it can be tricky to test the kernel datapath against
>> packets, as the first packets of each flow will have to go
>> through the ovs-vswitchd daemon. For instance, to do a zeroloss
>> performance test, you establish the flows, and then you have to
>> perform your zeroloss test before the flow is removed by
>> ovs-vswitchd.
>>
>> It is possible to configure a flow timeout in ovs-vswitchd (using
>> other_config:max-idle option), but it changes the behavior for
>> all the flows, which is not always what you want.
>
> It seems to me that it would be preferable to implement the necessary
> behavior in userspace to handle this directly. The logic that is
> removing the flow is in userspace, so rather than asking the kernel to
> lie about the current state of things, we can just modify the logic to
> handle this case.

It seemed like a problem limited to the kernel datapath (i.e.: not to
the other ovs datapaths), so it made sense to me to fix it by a
netlink API.
The idea was to do something similar to the OVS_FLOW_ATTR_CLEAR
attribute (which sets the flow statistics and used field to 0).

This said, I could have a look to a pure userland solution, but I am
not sure how to do it. Could you elaborate what you have in mind?

Thanks.