[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160805013138.GA52225@ast-mbp.thefacebook.com>
Date: Thu, 4 Aug 2016 18:31:40 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: kan.liang@...el.com
Cc: davem@...emloft.net, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, jeffrey.t.kirsher@...el.com,
mingo@...hat.com, peterz@...radead.org, kuznet@....inr.ac.ru,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
akpm@...ux-foundation.org, keescook@...omium.org,
viro@...iv.linux.org.uk, gorcunov@...nvz.org,
john.stultz@...aro.org, aduyck@...antis.com, ben@...adent.org.uk,
decot@...glers.com, fw@...len.de, alexander.duyck@...il.com,
daniel@...earbox.net, tom@...bertland.com, rdunlap@...radead.org,
xiyou.wangcong@...il.com, hannes@...essinduktion.org,
jesse.brandeburg@...el.com, andi@...stfloor.org
Subject: Re: [RFC V2 PATCH 00/25] Kernel NET policy
On Wed, Dec 31, 2014 at 08:38:49PM -0500, kan.liang@...el.com wrote:
>
> Changes since V1:
> - Using work queue to set Rx network flow classification rules and search
> available NET policy object asynchronously.
> - Using RCU lock to replace read-write lock
> - Redo performance test and update performance results.
> - Some minor modification for codes and documents.
> - Remove i40e related patches which will be submitted in separate thread.
Most of the issues brought up in the prior submission were not addressed,
so one more NACK from me as well.
My objection with this approach is the same as others:
such policy doesn't belong in the kernel.
> 1. Why userspace tool cannot do the same thing?
> A: Kernel is more suitable for NET policy.
> - User space code would be far more complicated to get right and perform
> well . It always need to work with out of date state compared to the
> latest, because it cannot do any locking with the kernel state.
> - User space code is less efficient than kernel code, because of the
> additional context switches needed.
> - Kernel is in the right position to coordinate requests from multiple
> users.
and above excuses is the reason to hack flow director rules in the kernel?
You can do the same in user space. It's not a kernel job.
Powered by blists - more mailing lists