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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 17 Mar 2016 15:54:01 -0700
From:	Jesse Gross <jesse@...nel.org>
To:	Samuel Gauthier <samuel.gauthier@...nd.com>
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

On Thu, Mar 17, 2016 at 9:24 AM, Samuel Gauthier
<samuel.gauthier@...nd.com> wrote:
> 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.

I don't think that is true - the flow eviction logic is in userspace,
so it should be common to all datapaths. What the kernel is providing
is really very simple, just the last used time.

> 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?

Well, truthfully, I would just use the existing max-idle option that
you mentioned. I'm not entirely sure what the issue is with it
applying to all flows, however, presumably it could be modified to
only apply to a subset if necessary. max-idle is implemented purely in
userspace, so I would start by looking at that and see how to tailor
it.