Hello Nithin,
Thanks for the review!
2. We'll have to get rid of the OvsDumpVportIoctl() sometime. We need not do
it in this patch itself.
I think the best time to remove it is when the netlink part is done. We could
add some #ifdef so people know it's not used when the netlink device is
Oh, I've sent reply with explanations before reading this reply of yours.
Anyway, I wrote explanations there for other things as well.
Regards,
Sam
From: Nithin Raju [nit...@vmware.com]
Sent: Friday, September 19, 2014 7:43 PM
To: Samuel Ghinet
Cc:
Sam,
It occurred to be that the patch you sent out dumps one part at a time, and I
was in the mindset that it should be dumping as many ports as the output buffer
allows, and hence there's a bug.
I am OK with dumping one port at a time for now and fixing the code later after
adding support for
I meant to send it to ML.
From: Samuel Ghinet
Sent: Wednesday, September 17, 2014 7:46 PM
To: Eitan Eliahu
Subject: RE: [PATCH v2] datapath-windows: Netlink command: vport dump
Hi Eitan,
Yes, you're right, I forgot to check the return values from the
hi Samuel,
Thanks for sending out the changes.
Some high level comments are:
1. You might have to rebase your change when Eitan's change gets checked in. He
has coalesced the declarations of the command handlers.
2. We'll have to get rid of the OvsDumpVportIoctl() sometime. We need not do it
in
Functionality for vport dump.
Later, when we will add more netlink dump commands, some common code will need
to be split to functions.
Notes:
a) the current implementation of vport assumes the datapath feature
multiple upcall pids is not used. A single upcall pid is used instead.
c) the vxlan
Hi Sam,
Looks good. Some comments:
Shouldn't we check the return code from NlMsgPutTailU32() ?
Do we check the size of the out message before we populate it with the port NL
attributes?
Thanks,
Eitan
-Original Message-
From: Samuel Ghinet [mailto:sghi...@cloudbasesolutions.com]
Sent:
