Thanks for the review Thomas~ ;D
Please see my reply inline:
It's nice to see that you preserve backwards compatibility but why
> rename the attribute? It doesn't really serve a purpose except that you
> break the API.
>
> Since OVS_VPORT_ATTR_UPCALL_PID was a single u32 it is already forward
> c
Hi Alex,
On 02/27/2014 08:44 PM, Alex Wang wrote:
diff --git a/datapath/datapath.c b/datapath/datapath.c
index f7c3391..de4b97a 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -1459,7 +1459,7 @@ static const struct nla_policy
vport_policy[OVS_VPORT_ATTR_MAX + 1] = {
[OVS_V
On Wed, Mar 5, 2014 at 10:43 AM, Ben Pfaff wrote:
> On Thu, Feb 27, 2014 at 11:44:24AM -0800, Alex Wang wrote:
> > In order to allow handlers directly read upcalls from datapath,
> > we need to support per-handler netlink socket for each vport in
> > datapath. This commit makes this happen. Als
On Thu, Feb 27, 2014 at 11:44:24AM -0800, Alex Wang wrote:
> In order to allow handlers directly read upcalls from datapath,
> we need to support per-handler netlink socket for each vport in
> datapath. This commit makes this happen. Also, it is guaranteed
> that the newer datapath is compatible
In order to allow handlers directly read upcalls from datapath,
we need to support per-handler netlink socket for each vport in
datapath. This commit makes this happen. Also, it is guaranteed
that the newer datapath is compatible with the branch-2.1 userspace
implementation.
Signed-off-by: Alex
