[ovs-dev] [Windows thread 2]
Alin Serdean
aserdean at cloudbasesolutions.com
Fri Dec 13 19:48:47 UTC 2013
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 [shettyg at nicira.com]
Sent: Friday, December 13, 2013 8:40 PM
To: Alin Serdean
Cc: Ben Pfaff; dev at 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
<aserdean at 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 [shettyg at nicira.com]
> Sent: Wednesday, December 11, 2013 8:27 PM
> To: Alin Serdean
> Cc: Ben Pfaff; dev at openvswitch.org
> Subject: Re: [ovs-dev] [Windows thread 2]
>
> On Wed, Dec 11, 2013 at 9:43 AM, Alin Serdean
> <aserdean at 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-bounces at openvswitch.org [dev-bounces at openvswitch.org] on behalf of Ben Pfaff [blp at nicira.com]
>> Sent: Wednesday, December 11, 2013 7:31 PM
>> To: Simon Horman
>> Cc: dev at 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 <horms at 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 at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>> _______________________________________________
>> dev mailing list
>> dev at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
More information about the dev
mailing list