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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEh+42jMSpPr8yUmmO355D=auKa-cGTwOZu0CSf-0=rczu4zwg@mail.gmail.com>
Date:	Wed, 16 Mar 2016 16:23:38 -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 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.