Not at all. I want to do a quick review myself over them before I send it in though.
Thanks for the explanation, I am quite new to this "world" :-). Kind Regards, Alin. ________________________________________ From: Gurucharan Shetty [shet...@nicira.com] Sent: Friday, December 13, 2013 8:40 PM To: Alin Serdean Cc: Ben Pfaff; dev@openvswitch.org Subject: Re: [ovs-dev] [Windows thread 2] Would you mind sending in a proper patch which includes your changes added to the mentioned patch for a review with a commit message and rationale. (The reviewers usually do a "git am 'patch.txt' and then review. And if there is a review comment, you re-spin the patch with the subject edited with a "V2" mentioned.) Thanks, Guru On Thu, Dec 12, 2013 at 2:22 PM, Alin Serdean <aserd...@cloudbasesolutions.com> wrote: > I applied your patch > (http://openvswitch.org/pipermail/dev/2013-November/034001.html) and added > the includes things started to compile :). > > But again it is up too you how the file structure will be in end. > > Kind Regards, > Alin. > ________________________________________ > From: Gurucharan Shetty [shet...@nicira.com] > Sent: Wednesday, December 11, 2013 8:27 PM > To: Alin Serdean > Cc: Ben Pfaff; dev@openvswitch.org > Subject: Re: [ovs-dev] [Windows thread 2] > > On Wed, Dec 11, 2013 at 9:43 AM, Alin Serdean > <aserd...@cloudbasesolutions.com> wrote: >> Hey, >> >> After the include_next from string.h(wrapper) will be solved we will be >> faced with another scenario. >> >> Unfortunately on MSVC we don't have inline we have __inline(see >> http://msdn.microsoft.com/en-us/library/cx3b23a3.aspx for more information) >> so it is either autoconf magic again :-) or an include that is used by all >> the header files. >> >> In our port I defined the following in config.h (brutal way of doing it ;-) >> ). >> #define ffs __lzcnt >> #define inline __inline >> #define strtok_r strtok_s >> #define __func__ __FUNCTION__ >> #define u_int8_t uint8_t >> #define u_int16_t uint16_t >> #define u_int32_t uint32_t >> #define u_int64_t uint64_t > > I had sent a patch couple of weeks back to solve a similar issue. (I > abandoned the patch for a different reason.) > http://openvswitch.org/pipermail/dev/2013-November/034001.html > > I wonder for this particular case, we can include the #defines inside > the windefs.h > > Thanks, > Guru > >> >> Kind Regards, >> Alin. >> ________________________________________ >> From: dev-boun...@openvswitch.org [dev-boun...@openvswitch.org] on behalf of >> Ben Pfaff [b...@nicira.com] >> Sent: Wednesday, December 11, 2013 7:31 PM >> To: Simon Horman >> Cc: dev@openvswitch.org >> Subject: Re: [ovs-dev] [PATCH RFC] netdev-linux: Read packet auxdata to >> obtain vlan_tid >> >> On Wed, Dec 11, 2013 at 11:24:14AM +0900, Simon Horman wrote: >>> If VLAN acceleration is used when the kernel receives a packet >>> then the outer-most VLAN tag will not be present in the packet >>> when it is received by netdev-linux. Rather, it will be present >>> in auxdata. >>> >>> This patch uses recvmsg() instead of recv() to read auxdata for >>> each packet and if the vlan_tid is set then it is added to the packet. >>> >>> Adding the vlan_tid to the packet involves copying most of the packet >>> and may be rather expensive. There is ample scope to avoid this by >>> passing the vlan_tid back to the caller separately to the packet itself >>> or providing access headroom in the packet. This would most likely >>> involve updating the netdev-class API. >>> >>> Signed-off-by: Simon Horman <ho...@verge.net.au> >> >> Thanks for doing this. >> >> I think that we should change netdev_class to pass an ofpbuf into >> rx_recv. Then we can just ofpbuf_reserve() VLAN_HEADER_LEN bytes >> before doing the receive, and just use eth_push_vlan() to insert the >> VLAN header. >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
