Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Ola Liljedahl]

On 20 October 2015 at 18:29, HePeng  wrote:

>
> 在 2015年10月19日，下午11:31，Ola Liljedahl  写道：
>
> On 16 October 2015 at 04:59, HePeng  wrote:
>
>>
>> 在 2015年10月16日，上午4:19，Ola Liljedahl  写道：
>>
>>
>>
>> On 12 October 2015 at 16:30, Maxim Uvarov 
>> wrote:
>>
>>> On 10/09/2015 16:27, HePeng wrote:
>>>

 在 2015年10月9日，下午8:20，Maxim Uvarov > 写道：
>
> Please specify git commit hash related to original code.
>
> I'm thinking how to maintain that in future.  And looks like there
> will be no way other then walk over all new patches
> and modify them to our odp code. In that case reference to original
> git base will be helpful.
>
> Thank you,
> Maxim.
>

 Rujiacs is my colleague. She has proposed in total 5 patches for hash
 table implementations (imported from DPDK):

 [5/5] Add test program for hash lib
 [4/5] Add four byte key hash table
 [3/5] Add cuckoo hash table
 [2/5] Modify the Ring structure
 [1/5] Add Jhash and CRC functions

 The 5 patches are currently all in the helper/ directory (they are not
 APIs).

 All these patches have been discussed and reviewed (except 2/5, however
 it has been already used by some one. I’ve seen it in the mail list).
 Here is the outcome of the discussions:

 For hash table implementations, the reviews focus on the convention
 differences between DPDK and ODP.
 For hash functions, some people think that CRC should be put in the
 odp/include as a public API.
 I am a little bit confused with what to do next.
 Maybe going back to firstly add the hash functions and then merging the
 hash table implementations can make all these patches clear?


 The first step includes:

 1) add a generic hash APIs into API-NEXT branches ( in include/odp)

 2) add  CRC hash APIs into the API-NEXT branches ( in include/odp),
 and put SW implementations in the linux-generic. CRC is special since
 many
 cpus have CRC accelerated instructions.

 2) add Jhash implementations in helper/

 Then,

 1) add 2 hash tables implementations in helper/


 How about this ?
 Thanks.

>>>
>>> Hello He,
>>>
>>> we discussed today on meeting that. That is good steps to go. 1) crc odp
>>> api + it's linux-generic implementation 2) jhash for helper.
>>>
>>> For crc you can use simple crc(void *ptr, size_t len) for first version.
>>> I.e. do not take care about packet segmentation, and later
>>> we will switch it to segmented version crc(odp_packet_t pkt).
>>>
>> I doubt you want to compute the CRC over all of the data in a packet,
>> selected pieces of the actual payload seems more realistic. As usual, we
>> need an actual use case to drive the API definition
>>
>>
>> Hi Ola,
>>   CRC can be used as a hash function as well as to verify the packet
>> payload. A well-known usage is to re-calculate the crc code after TTL minus
>> 1.
>>
> Can you elaborate on this? The IP header contains a checksum that needs to
> be updated when the TTL field is decremented. But the IP header checksum is
> using ones complement checksum. There are also optimised ways of adjusting
> the checksum when the TTL field is decremented by one without having to
> recompute the whole checksum.
>
>
> Sorry, I made a mistake thinking that the IP header is using CRC as the
> checksum of the packet.
> My original thought is to add a CRC as a hash function alternative.
>
>
>
>> However, modern network card or network processor usually has built-in
>> hardware logic that can re-calculate crc automatically. In my opinion, crc
>> is more likely being used as a hash function in many dataplane programs.
>>
> What I mean is that a CRC function should take a pointer and a size as
> parameters (as you first suggest), not a packet handle (as you suggest
> later). I doubt you want to compute the CRC over a whole packet. E.g. for
> SCTP, it is only the payload that is being checksummed (using CRC32c),
> headers should not be included. If you want to compute the CRC for some
> other object, this might not be representable as a packet.
>
> Is there any use case where you want to compute the CRC for a whole packet
> and thus passing a packet handle is the best choice? We are not very
> interested in computing Ethernet FCS I think.
>
> The payload CRC computing API is proposed by Maxim. I am following the
> outcome of a disscution to add a pure CRC API.
>
I don't understand the difference.
When would you use the CRC function that you propose to add to ODP?



>
>
>
>
>
>>
>>
>>
>>
>>
>>>
>>> Thanks,
>>> Maxim.
>>>
>>>
>>>
>>>

>
> On 10/09/15 11:37, HePeng wrote:
>
>>
>> 在 2015年10月9日，下午4:36，Ola Liljedahl > 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Bill Fischofer]

Barry has done some recent work on hash functions and it seems that AES
provides a much better distribution than CRC, and with very good
performance on those platforms that have AES instructions.

On Thu, Oct 15, 2015 at 9:59 PM, HePeng  wrote:

>
> 在 2015年10月16日，上午4:19，Ola Liljedahl  写道：
>
>
>
> On 12 October 2015 at 16:30, Maxim Uvarov  wrote:
>
>> On 10/09/2015 16:27, HePeng wrote:
>>
>>>
>>> 在 2015年10月9日，下午8:20，Maxim Uvarov >> maxim.uva...@linaro.org>> 写道：

 Please specify git commit hash related to original code.

 I'm thinking how to maintain that in future.  And looks like there will
 be no way other then walk over all new patches
 and modify them to our odp code. In that case reference to original git
 base will be helpful.

 Thank you,
 Maxim.

>>>
>>> Rujiacs is my colleague. She has proposed in total 5 patches for hash
>>> table implementations (imported from DPDK):
>>>
>>> [5/5] Add test program for hash lib
>>> [4/5] Add four byte key hash table
>>> [3/5] Add cuckoo hash table
>>> [2/5] Modify the Ring structure
>>> [1/5] Add Jhash and CRC functions
>>>
>>> The 5 patches are currently all in the helper/ directory (they are not
>>> APIs).
>>>
>>> All these patches have been discussed and reviewed (except 2/5, however
>>> it has been already used by some one. I’ve seen it in the mail list).
>>> Here is the outcome of the discussions:
>>>
>>> For hash table implementations, the reviews focus on the convention
>>> differences between DPDK and ODP.
>>> For hash functions, some people think that CRC should be put in the
>>> odp/include as a public API.
>>> I am a little bit confused with what to do next.
>>> Maybe going back to firstly add the hash functions and then merging the
>>> hash table implementations can make all these patches clear?
>>>
>>>
>>> The first step includes:
>>>
>>> 1) add a generic hash APIs into API-NEXT branches ( in include/odp)
>>>
>>> 2) add  CRC hash APIs into the API-NEXT branches ( in include/odp),
>>> and put SW implementations in the linux-generic. CRC is special since
>>> many
>>> cpus have CRC accelerated instructions.
>>>
>>> 2) add Jhash implementations in helper/
>>>
>>> Then,
>>>
>>> 1) add 2 hash tables implementations in helper/
>>>
>>>
>>> How about this ?
>>> Thanks.
>>>
>>
>> Hello He,
>>
>> we discussed today on meeting that. That is good steps to go. 1) crc odp
>> api + it's linux-generic implementation 2) jhash for helper.
>>
>> For crc you can use simple crc(void *ptr, size_t len) for first version.
>> I.e. do not take care about packet segmentation, and later
>> we will switch it to segmented version crc(odp_packet_t pkt).
>>
> I doubt you want to compute the CRC over all of the data in a packet,
> selected pieces of the actual payload seems more realistic. As usual, we
> need an actual use case to drive the API definition
>
>
> Hi Ola,
>   CRC can be used as a hash function as well as to verify the packet
> payload. A well-known usage is to re-calculate the crc code after TTL minus
> 1. However, modern network card or network processor usually has built-in
> hardware logic that can re-calculate crc automatically. In my opinion, crc
> is more likely being used as a hash function in many dataplane programs.
>
>
>
>
>
>>
>> Thanks,
>> Maxim.
>>
>>
>>
>>
>>>

 On 10/09/15 11:37, HePeng wrote:

>
> 在 2015年10月9日，下午4:36，Ola Liljedahl  ola.liljed...@linaro.org>> 写道：
>>
>> On 9 October 2015 at 10:33, HePeng  xnhp0...@icloud.com>> wrote:
>>
>>
>>在 2015年10月9日，下午4:26，Ola Liljedahl
>>>
>>> > 写道：
>>>
>>>On 8 October 2015 at 14:43, HePeng > xnhp0...@icloud.com>
>>>> wrote:
>>>
>>>
>>>在 2015年10月8日，下午8:13，Ola Liljedahl

> 写道：

On 8 October 2015 at 10:02, Bill Fischofer

> wrote:

Trying to keep the rte_ prefix would be confusing.  One
of the precepts of ODP is that it doesn't preclude an
application also using an underlying SDK in addition to
ODP APIs. Whether that makes sense is up to the
application, of course.  But if ODP were to start using
other prefixes I'd imagine that would get very messy.

It would also be confusing to have functions 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Bill Fischofer]

My point is only that a hash API stands by itself, as would a CRC API.

On Fri, Oct 16, 2015 at 9:26 AM, HePeng  wrote:

>
> 在 2015年10月16日，下午8:44，Bill Fischofer  写道：
>
> Barry has done some recent work on hash functions and it seems that AES
> provides a much better distribution than CRC, and with very good
> performance on those platforms that have AES instructions.
>
>
> I do not see your point. Do you mean that it is not necessary to have CRC
> as an ODP API?
> I think Barry’s work can be useful to choose which hash function as a
> default one, but
> does it mean that we do not need a CRC API in ODP? All in all, we may need
> CRC as a
> sort of check code.
>
> Perhaps it is better to have a general hash function API?
>
>
>
>
> On Thu, Oct 15, 2015 at 9:59 PM, HePeng  wrote:
>
>>
>> 在 2015年10月16日，上午4:19，Ola Liljedahl  写道：
>>
>>
>>
>> On 12 October 2015 at 16:30, Maxim Uvarov 
>> wrote:
>>
>>> On 10/09/2015 16:27, HePeng wrote:
>>>

 在 2015年10月9日，下午8:20，Maxim Uvarov > 写道：
>
> Please specify git commit hash related to original code.
>
> I'm thinking how to maintain that in future.  And looks like there
> will be no way other then walk over all new patches
> and modify them to our odp code. In that case reference to original
> git base will be helpful.
>
> Thank you,
> Maxim.
>

 Rujiacs is my colleague. She has proposed in total 5 patches for hash
 table implementations (imported from DPDK):

 [5/5] Add test program for hash lib
 [4/5] Add four byte key hash table
 [3/5] Add cuckoo hash table
 [2/5] Modify the Ring structure
 [1/5] Add Jhash and CRC functions

 The 5 patches are currently all in the helper/ directory (they are not
 APIs).

 All these patches have been discussed and reviewed (except 2/5, however
 it has been already used by some one. I’ve seen it in the mail list).
 Here is the outcome of the discussions:

 For hash table implementations, the reviews focus on the convention
 differences between DPDK and ODP.
 For hash functions, some people think that CRC should be put in the
 odp/include as a public API.
 I am a little bit confused with what to do next.
 Maybe going back to firstly add the hash functions and then merging the
 hash table implementations can make all these patches clear?


 The first step includes:

 1) add a generic hash APIs into API-NEXT branches ( in include/odp)

 2) add  CRC hash APIs into the API-NEXT branches ( in include/odp),
 and put SW implementations in the linux-generic. CRC is special since
 many
 cpus have CRC accelerated instructions.

 2) add Jhash implementations in helper/

 Then,

 1) add 2 hash tables implementations in helper/


 How about this ?
 Thanks.

>>>
>>> Hello He,
>>>
>>> we discussed today on meeting that. That is good steps to go. 1) crc odp
>>> api + it's linux-generic implementation 2) jhash for helper.
>>>
>>> For crc you can use simple crc(void *ptr, size_t len) for first version.
>>> I.e. do not take care about packet segmentation, and later
>>> we will switch it to segmented version crc(odp_packet_t pkt).
>>>
>> I doubt you want to compute the CRC over all of the data in a packet,
>> selected pieces of the actual payload seems more realistic. As usual, we
>> need an actual use case to drive the API definition
>>
>>
>> Hi Ola,
>>   CRC can be used as a hash function as well as to verify the packet
>> payload. A well-known usage is to re-calculate the crc code after TTL minus
>> 1. However, modern network card or network processor usually has built-in
>> hardware logic that can re-calculate crc automatically. In my opinion, crc
>> is more likely being used as a hash function in many dataplane programs.
>>
>>
>>
>>
>>
>>>
>>> Thanks,
>>> Maxim.
>>>
>>>
>>>
>>>

>
> On 10/09/15 11:37, HePeng wrote:
>
>>
>> 在 2015年10月9日，下午4:36，Ola Liljedahl > ola.liljed...@linaro.org>> 写道：
>>>
>>> On 9 October 2015 at 10:33, HePeng > xnhp0...@icloud.com>> wrote:
>>>
>>>
>>>在 2015年10月9日，下午4:26，Ola Liljedahl

 > 写道：

On 8 October 2015 at 14:43, HePeng >> xnhp0...@icloud.com>
> wrote:


在 2015年10月8日，下午8:13，Ola Liljedahl
>
>> 写道：
>
>   

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Ola Liljedahl]

On 12 October 2015 at 16:30, Maxim Uvarov  wrote:

> On 10/09/2015 16:27, HePeng wrote:
>
>>
>> 在 2015年10月9日，下午8:20，Maxim Uvarov > maxim.uva...@linaro.org>> 写道：
>>>
>>> Please specify git commit hash related to original code.
>>>
>>> I'm thinking how to maintain that in future.  And looks like there will
>>> be no way other then walk over all new patches
>>> and modify them to our odp code. In that case reference to original git
>>> base will be helpful.
>>>
>>> Thank you,
>>> Maxim.
>>>
>>
>> Rujiacs is my colleague. She has proposed in total 5 patches for hash
>> table implementations (imported from DPDK):
>>
>> [5/5] Add test program for hash lib
>> [4/5] Add four byte key hash table
>> [3/5] Add cuckoo hash table
>> [2/5] Modify the Ring structure
>> [1/5] Add Jhash and CRC functions
>>
>> The 5 patches are currently all in the helper/ directory (they are not
>> APIs).
>>
>> All these patches have been discussed and reviewed (except 2/5, however
>> it has been already used by some one. I’ve seen it in the mail list).
>> Here is the outcome of the discussions:
>>
>> For hash table implementations, the reviews focus on the convention
>> differences between DPDK and ODP.
>> For hash functions, some people think that CRC should be put in the
>> odp/include as a public API.
>> I am a little bit confused with what to do next.
>> Maybe going back to firstly add the hash functions and then merging the
>> hash table implementations can make all these patches clear?
>>
>>
>> The first step includes:
>>
>> 1) add a generic hash APIs into API-NEXT branches ( in include/odp)
>>
>> 2) add  CRC hash APIs into the API-NEXT branches ( in include/odp),
>> and put SW implementations in the linux-generic. CRC is special since many
>> cpus have CRC accelerated instructions.
>>
>> 2) add Jhash implementations in helper/
>>
>> Then,
>>
>> 1) add 2 hash tables implementations in helper/
>>
>>
>> How about this ?
>> Thanks.
>>
>
> Hello He,
>
> we discussed today on meeting that. That is good steps to go. 1) crc odp
> api + it's linux-generic implementation 2) jhash for helper.
>
> For crc you can use simple crc(void *ptr, size_t len) for first version.
> I.e. do not take care about packet segmentation, and later
> we will switch it to segmented version crc(odp_packet_t pkt).
>
I doubt you want to compute the CRC over all of the data in a packet,
selected pieces of the actual payload seems more realistic. As usual, we
need an actual use case to drive the API definition.



>
> Thanks,
> Maxim.
>
>
>
>
>>
>>>
>>> On 10/09/15 11:37, HePeng wrote:
>>>

 在 2015年10月9日，下午4:36，Ola Liljedahl > 写道：
>
> On 9 October 2015 at 10:33, HePeng > wrote:
>
>
>在 2015年10月9日，下午4:26，Ola Liljedahl
>>
>> > 写道：
>>
>>On 8 October 2015 at 14:43, HePeng  xnhp0...@icloud.com>
>>> wrote:
>>
>>
>>在 2015年10月8日，下午8:13，Ola Liljedahl
>>>
>>>> 写道：
>>>
>>>On 8 October 2015 at 10:02, Bill Fischofer
>>>
>>>> wrote:
>>>
>>>Trying to keep the rte_ prefix would be confusing.  One
>>>of the precepts of ODP is that it doesn't preclude an
>>>application also using an underlying SDK in addition to
>>>ODP APIs. Whether that makes sense is up to the
>>>application, of course.  But if ODP were to start using
>>>other prefixes I'd imagine that would get very messy.
>>>
>>>It would also be confusing to have functions that use odp_
>>>naming conventions but don't behave like ODP functions
>>>(with regards to e.g. handling and returning errors or
>>>checking parameters).
>>>
>>We can fix this by wrapping these functions.
>>
>>I don't follow you. How can you make these function behave like
>>ODP functions by "wrapping" them?
>>Me thinks you have to modify the implementation in order to
>>change the behaviour.
>>
>
>I mean that perhaps not all the functions needs to be changed,
>only the exposed ones (APIs). Some functions are static and are
>only used in
>the internal of implementation, these functions can reserve their
>code.
>
> Static functions can have whatever names you like. But if their
> implementation contributes to the behaviour 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Maxim Uvarov]

On 10/09/2015 16:27, HePeng wrote:


在 2015年10月9日，下午8:20，Maxim Uvarov > 写道：


Please specify git commit hash related to original code.

I'm thinking how to maintain that in future.  And looks like there 
will be no way other then walk over all new patches
and modify them to our odp code. In that case reference to original 
git base will be helpful.


Thank you,
Maxim.


Rujiacs is my colleague. She has proposed in total 5 patches for hash 
table implementations (imported from DPDK):


[5/5] Add test program for hash lib
[4/5] Add four byte key hash table
[3/5] Add cuckoo hash table
[2/5] Modify the Ring structure
[1/5] Add Jhash and CRC functions

The 5 patches are currently all in the helper/ directory (they are not 
APIs).


All these patches have been discussed and reviewed (except 2/5, 
however it has been already used by some one. I’ve seen it in the mail 
list).

Here is the outcome of the discussions:

For hash table implementations, the reviews focus on the convention 
differences between DPDK and ODP.
For hash functions, some people think that CRC should be put in the 
odp/include as a public API.

I am a little bit confused with what to do next.
Maybe going back to firstly add the hash functions and then merging 
the hash table implementations can make all these patches clear?



The first step includes:

1) add a generic hash APIs into API-NEXT branches ( in include/odp)

2) add  CRC hash APIs into the API-NEXT branches ( in include/odp),
and put SW implementations in the linux-generic. CRC is special since 
many

cpus have CRC accelerated instructions.

2) add Jhash implementations in helper/

Then,

1) add 2 hash tables implementations in helper/


How about this ?
Thanks.


Hello He,

we discussed today on meeting that. That is good steps to go. 1) crc odp 
api + it's linux-generic implementation 2) jhash for helper.


For crc you can use simple crc(void *ptr, size_t len) for first version. 
I.e. do not take care about packet segmentation, and later

we will switch it to segmented version crc(odp_packet_t pkt).

Thanks,
Maxim.








On 10/09/15 11:37, HePeng wrote:


在 2015年10月9日，下午4:36，Ola Liljedahl > 
写道：


On 9 October 2015 at 10:33, HePeng > wrote:




   在 2015年10月9日，下午4:26，Ola Liljedahl
    
> 写道：


   On 8 October 2015 at 14:43, HePeng 

   > wrote:



   在 2015年10月8日，下午8:13，Ola Liljedahl
   
   > 写道：

   On 8 October 2015 at 10:02, Bill Fischofer
   
   > wrote:

   Trying to keep the rte_ prefix would be confusing.  One
   of the precepts of ODP is that it doesn't preclude an
   application also using an underlying SDK in addition to
   ODP APIs. Whether that makes sense is up to the
   application, of course.  But if ODP were to start using
   other prefixes I'd imagine that would get very messy.

   It would also be confusing to have functions that use odp_
   naming conventions but don't behave like ODP functions
   (with regards to e.g. handling and returning errors or
   checking parameters).

   We can fix this by wrapping these functions.

   I don't follow you. How can you make these function behave like
   ODP functions by "wrapping" them?
   Me thinks you have to modify the implementation in order to
   change the behaviour.


   I mean that perhaps not all the functions needs to be changed,
   only the exposed ones (APIs). Some functions are static and are
   only used in
   the internal of implementation, these functions can reserve their
   code.

Static functions can have whatever names you like. But if their 
implementation contributes to the behaviour as seen by callers of 
the public functions, that behaviour must be compliant with the ODP 
style.


I see. Thanks.






But considering that the internal code is already ready, I
   am thinking reserve the code of *static* functions (internal
   implementations)?





   So if we rename code imported from e.g. DPDK, we should
   also convert it to behave like proper ODP functions. That
   we can base the implementation on preexisting code is just
   incidental and should not affect how the code behaves.


   On Wednesday, October 7, 2015, Ola Liljedahl
   

   > wrote:

   On 23 September 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Ola Liljedahl]

On 9 October 2015 at 10:33, HePeng  wrote:

>
> 在 2015年10月9日，下午4:26，Ola Liljedahl  写道：
>
> On 8 October 2015 at 14:43, HePeng  wrote:
>
>>
>> 在 2015年10月8日，下午8:13，Ola Liljedahl  写道：
>>
>> On 8 October 2015 at 10:02, Bill Fischofer 
>> wrote:
>>
>>> Trying to keep the rte_ prefix would be confusing.  One of the precepts
>>> of ODP is that it doesn't preclude an application also using an underlying
>>> SDK in addition to ODP APIs.  Whether that makes sense is up to the
>>> application, of course.  But if ODP were to start using other prefixes I'd
>>> imagine that would get very messy.
>>
>> It would also be confusing to have functions that use odp_ naming
>> conventions but don't behave like ODP functions (with regards to e.g.
>> handling and returning errors or checking parameters).
>>
>> We can fix this by wrapping these functions.
>>
> I don't follow you. How can you make these function behave like ODP
> functions by "wrapping" them?
> Me thinks you have to modify the implementation in order to change the
> behaviour.
>
>
> I mean that perhaps not all the functions needs to be changed, only the
> exposed ones (APIs). Some functions are static and are only used in
> the internal of implementation, these functions can reserve their code.
>
Static functions can have whatever names you like. But if their
implementation contributes to the behaviour as seen by callers of the
public functions, that behaviour must be compliant with the ODP style.


>
>
>  But considering that the internal code is already ready, I am thinking
>> reserve the code of *static* functions (internal implementations)?
>>
>>
>>
>>
>> So if we rename code imported from e.g. DPDK, we should also convert it
>> to behave like proper ODP functions. That we can base the implementation on
>> preexisting code is just incidental and should not affect how the code
>> behaves.
>>
>>
>>> On Wednesday, October 7, 2015, Ola Liljedahl 
>>> wrote:
>>>
 On 23 September 2015 at 19:51, Maxim Uvarov 
 wrote:

>
>
> On 09/20/15 07:04, rujiacs wrote:
>
>> Signed-off-by: rujiacs 
>> ---
>>   helper/hash_fbk.c| 179 
>>   helper/include/odp/helper/hash_fbk.h | 404
>> +++
>>   2 files changed, 583 insertions(+)
>>   create mode 100644 helper/hash_fbk.c
>>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>>
>> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>> new file mode 100644
>> index 000..eae7596
>> --- /dev/null
>> +++ b/helper/hash_fbk.c
>> @@ -0,0 +1,179 @@
>> +/**
>> + *   BSD LICENSE
>> + *
>> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>> + *   All rights reserved.
>> + *
>> + *   Redistribution and use in source and binary forms, with or
>> without
>> + *   modification, are permitted provided that the following
>> conditions
>> + *   are met:
>> + *
>> + * * Redistributions of source code must retain the above
>> copyright
>> + *   notice, this list of conditions and the following
>> disclaimer.
>> + * * Redistributions in binary form must reproduce the above
>> copyright
>> + *   notice, this list of conditions and the following
>> disclaimer in
>> + *   the documentation and/or other materials provided with the
>> + *   distribution.
>> + * * Neither the name of Intel Corporation nor the names of its
>> + *   contributors may be used to endorse or promote products
>> derived
>> + *   from this software without specific prior written
>> permission.
>> + *
>> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>> CONTRIBUTORS
>> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
>> NOT
>> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
>> FITNESS FOR
>> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
>> COPYRIGHT
>> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>> INCIDENTAL,
>> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
>> OF USE,
>> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>> ON ANY
>> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
>> TORT
>> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
>> THE USE
>> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>> DAMAGE.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Ola Liljedahl]

On 8 October 2015 at 14:43, HePeng  wrote:

>
> 在 2015年10月8日，下午8:13，Ola Liljedahl  写道：
>
> On 8 October 2015 at 10:02, Bill Fischofer 
> wrote:
>
>> Trying to keep the rte_ prefix would be confusing.  One of the precepts
>> of ODP is that it doesn't preclude an application also using an underlying
>> SDK in addition to ODP APIs.  Whether that makes sense is up to the
>> application, of course.  But if ODP were to start using other prefixes I'd
>> imagine that would get very messy.
>
> It would also be confusing to have functions that use odp_ naming
> conventions but don't behave like ODP functions (with regards to e.g.
> handling and returning errors or checking parameters).
>
> We can fix this by wrapping these functions.
>
I don't follow you. How can you make these function behave like ODP
functions by "wrapping" them?
Me thinks you have to modify the implementation in order to change the
behaviour.

 But considering that the internal code is already ready, I am thinking
> reserve the code of *static* functions (internal implementations)?
>
>
>
>
> So if we rename code imported from e.g. DPDK, we should also convert it to
> behave like proper ODP functions. That we can base the implementation on
> preexisting code is just incidental and should not affect how the code
> behaves.
>
>
>> On Wednesday, October 7, 2015, Ola Liljedahl 
>> wrote:
>>
>>> On 23 September 2015 at 19:51, Maxim Uvarov 
>>> wrote:
>>>


 On 09/20/15 07:04, rujiacs wrote:

> Signed-off-by: rujiacs 
> ---
>   helper/hash_fbk.c| 179 
>   helper/include/odp/helper/hash_fbk.h | 404
> +++
>   2 files changed, 583 insertions(+)
>   create mode 100644 helper/hash_fbk.c
>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>
> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
> new file mode 100644
> index 000..eae7596
> --- /dev/null
> +++ b/helper/hash_fbk.c
> @@ -0,0 +1,179 @@
> +/**
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> + *   All rights reserved.
> + *
> + *   Redistribution and use in source and binary forms, with or
> without
> + *   modification, are permitted provided that the following
> conditions
> + *   are met:
> + *
> + * * Redistributions of source code must retain the above
> copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above
> copyright
> + *   notice, this list of conditions and the following disclaimer
> in
> + *   the documentation and/or other materials provided with the
> + *   distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + *   contributors may be used to endorse or promote products
> derived
> + *   from this software without specific prior written permission.
> + *
> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> USE,
> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> ON ANY
> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include "odph_debug.h"
> +#include 
> +
> +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
> +static odp_rwlock_t fbk_hash_lock;
> +
> +void
> +odp_fbk_hash_list_init()
> +{
> +TAILQ_INIT(_hash_list);
> +odp_rwlock_init(_hash_lock);
> +}
> +
> +/**
> + * Performs a lookup for an existing hash table, and returns a
> pointer to
> + * the table if found.
> + *
> + * @param name
> + *   Name of the hash table to find
> + *
> + * @return
> + *   pointer to hash table structure or NULL on error.
> + */
> +struct odp_fbk_hash_table *
> 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[HePeng]

> 在 2015年10月9日，下午4:36，Ola Liljedahl  写道：
> 
> On 9 October 2015 at 10:33, HePeng  > wrote:
> 
>> 在 2015年10月9日，下午4:26，Ola Liljedahl > > 写道：
>> 
>> On 8 October 2015 at 14:43, HePeng > > wrote:
>> 
>>> 在 2015年10月8日，下午8:13，Ola Liljedahl >> > 写道：
>>> 
>>> On 8 October 2015 at 10:02, Bill Fischofer >> > wrote:
>>> Trying to keep the rte_ prefix would be confusing.  One of the precepts of 
>>> ODP is that it doesn't preclude an application also using an underlying SDK 
>>> in addition to ODP APIs.  Whether that makes sense is up to the 
>>> application, of course.  But if ODP were to start using other prefixes I'd 
>>> imagine that would get very messy.
>>> It would also be confusing to have functions that use odp_ naming 
>>> conventions but don't behave like ODP functions (with regards to e.g. 
>>> handling and returning errors or checking parameters).
>> 
>> We can fix this by wrapping these functions.
>> I don't follow you. How can you make these function behave like ODP 
>> functions by "wrapping" them?
>> Me thinks you have to modify the implementation in order to change the 
>> behaviour.
> 
> I mean that perhaps not all the functions needs to be changed, only the 
> exposed ones (APIs). Some functions are static and are only used in  
> the internal of implementation, these functions can reserve their code. 
> Static functions can have whatever names you like. But if their 
> implementation contributes to the behaviour as seen by callers of the public 
> functions, that behaviour must be compliant with the ODP style.

I see. Thanks. 


>  
> 
>> 
>>  But considering that the internal code is already ready, I am thinking 
>> reserve the code of *static* functions (internal implementations)?
>> 
>> 
>> 
>>> 
>>> So if we rename code imported from e.g. DPDK, we should also convert it to 
>>> behave like proper ODP functions. That we can base the implementation on 
>>> preexisting code is just incidental and should not affect how the code 
>>> behaves.
>>> 
>>> 
>>> On Wednesday, October 7, 2015, Ola Liljedahl >> > wrote:
>>> On 23 September 2015 at 19:51, Maxim Uvarov > 
>>> wrote:
>>> 
>>> 
>>> On 09/20/15 07:04, rujiacs wrote:
>>> Signed-off-by: rujiacs >
>>> ---
>>>   helper/hash_fbk.c| 179 
>>>   helper/include/odp/helper/hash_fbk.h | 404 
>>> +++
>>>   2 files changed, 583 insertions(+)
>>>   create mode 100644 helper/hash_fbk.c
>>>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>>> 
>>> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>>> new file mode 100644
>>> index 000..eae7596
>>> --- /dev/null
>>> +++ b/helper/hash_fbk.c
>>> @@ -0,0 +1,179 @@
>>> +/**
>>> + *   BSD LICENSE
>>> + *
>>> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>>> + *   All rights reserved.
>>> + *
>>> + *   Redistribution and use in source and binary forms, with or without
>>> + *   modification, are permitted provided that the following conditions
>>> + *   are met:
>>> + *
>>> + * * Redistributions of source code must retain the above copyright
>>> + *   notice, this list of conditions and the following disclaimer.
>>> + * * Redistributions in binary form must reproduce the above copyright
>>> + *   notice, this list of conditions and the following disclaimer in
>>> + *   the documentation and/or other materials provided with the
>>> + *   distribution.
>>> + * * Neither the name of Intel Corporation nor the names of its
>>> + *   contributors may be used to endorse or promote products derived
>>> + *   from this software without specific prior written permission.
>>> + *
>>> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>>> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>>> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>>> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>>> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>>> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>>> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[HePeng]

> 在 2015年10月9日，下午4:26，Ola Liljedahl  写道：
> 
> On 8 October 2015 at 14:43, HePeng  > wrote:
> 
>> 在 2015年10月8日，下午8:13，Ola Liljedahl > > 写道：
>> 
>> On 8 October 2015 at 10:02, Bill Fischofer > > wrote:
>> Trying to keep the rte_ prefix would be confusing.  One of the precepts of 
>> ODP is that it doesn't preclude an application also using an underlying SDK 
>> in addition to ODP APIs.  Whether that makes sense is up to the application, 
>> of course.  But if ODP were to start using other prefixes I'd imagine that 
>> would get very messy.
>> It would also be confusing to have functions that use odp_ naming 
>> conventions but don't behave like ODP functions (with regards to e.g. 
>> handling and returning errors or checking parameters).
> 
> We can fix this by wrapping these functions.
> I don't follow you. How can you make these function behave like ODP functions 
> by "wrapping" them?
> Me thinks you have to modify the implementation in order to change the 
> behaviour.

I mean that perhaps not all the functions needs to be changed, only the exposed 
ones (APIs). Some functions are static and are only used in  
the internal of implementation, these functions can reserve their code. 

> 
>  But considering that the internal code is already ready, I am thinking 
> reserve the code of *static* functions (internal implementations)?
> 
> 
> 
>> 
>> So if we rename code imported from e.g. DPDK, we should also convert it to 
>> behave like proper ODP functions. That we can base the implementation on 
>> preexisting code is just incidental and should not affect how the code 
>> behaves.
>> 
>> 
>> On Wednesday, October 7, 2015, Ola Liljedahl > > wrote:
>> On 23 September 2015 at 19:51, Maxim Uvarov > 
>> wrote:
>> 
>> 
>> On 09/20/15 07:04, rujiacs wrote:
>> Signed-off-by: rujiacs >
>> ---
>>   helper/hash_fbk.c| 179 
>>   helper/include/odp/helper/hash_fbk.h | 404 
>> +++
>>   2 files changed, 583 insertions(+)
>>   create mode 100644 helper/hash_fbk.c
>>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>> 
>> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>> new file mode 100644
>> index 000..eae7596
>> --- /dev/null
>> +++ b/helper/hash_fbk.c
>> @@ -0,0 +1,179 @@
>> +/**
>> + *   BSD LICENSE
>> + *
>> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>> + *   All rights reserved.
>> + *
>> + *   Redistribution and use in source and binary forms, with or without
>> + *   modification, are permitted provided that the following conditions
>> + *   are met:
>> + *
>> + * * Redistributions of source code must retain the above copyright
>> + *   notice, this list of conditions and the following disclaimer.
>> + * * Redistributions in binary form must reproduce the above copyright
>> + *   notice, this list of conditions and the following disclaimer in
>> + *   the documentation and/or other materials provided with the
>> + *   distribution.
>> + * * Neither the name of Intel Corporation nor the names of its
>> + *   contributors may be used to endorse or promote products derived
>> + *   from this software without specific prior written permission.
>> + *
>> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include "odph_debug.h"
>> +#include 
>> +
>> +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
>> +static odp_rwlock_t fbk_hash_lock;
>> +
>> +void
>> +odp_fbk_hash_list_init()
>> +{
>> +TAILQ_INIT(_hash_list);
>> +odp_rwlock_init(_hash_lock);
>> +}
>> +
>> +/**
>> + * Performs a lookup for an existing hash table, and returns a pointer to
>> + * the table if found.
>> + *
>> + * @param name
>> + *   Name of the hash table to find
>> + *
>> + * @return
>> 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Maxim Uvarov]

Please specify git commit hash related to original code.

I'm thinking how to maintain that in future.  And looks like there will 
be no way other then walk over all new patches
and modify them to our odp code. In that case reference to original git 
base will be helpful.


Thank you,
Maxim.


On 10/09/15 11:37, HePeng wrote:


在 2015年10月9日，下午4:36，Ola Liljedahl > 写道：


On 9 October 2015 at 10:33, HePeng > wrote:




在 2015年10月9日，下午4:26，Ola Liljedahl
> 写道：

On 8 October 2015 at 14:43, HePeng > wrote:



在 2015年10月8日，下午8:13，Ola Liljedahl
> 写道：

On 8 October 2015 at 10:02, Bill Fischofer
> wrote:

Trying to keep the rte_ prefix would be confusing.  One
of the precepts of ODP is that it doesn't preclude an
application also using an underlying SDK in addition to
ODP APIs. Whether that makes sense is up to the
application, of course.  But if ODP were to start using
other prefixes I'd imagine that would get very messy.

It would also be confusing to have functions that use odp_
naming conventions but don't behave like ODP functions
(with regards to e.g. handling and returning errors or
checking parameters).

We can fix this by wrapping these functions.

I don't follow you. How can you make these function behave like
ODP functions by "wrapping" them?
Me thinks you have to modify the implementation in order to
change the behaviour.


I mean that perhaps not all the functions needs to be changed,
only the exposed ones (APIs). Some functions are static and are
only used in
the internal of implementation, these functions can reserve their
code.

Static functions can have whatever names you like. But if their 
implementation contributes to the behaviour as seen by callers of the 
public functions, that behaviour must be compliant with the ODP style.


I see. Thanks.






 But considering that the internal code is already ready, I
am thinking reserve the code of *static* functions (internal
implementations)?





So if we rename code imported from e.g. DPDK, we should
also convert it to behave like proper ODP functions. That
we can base the implementation on preexisting code is just
incidental and should not affect how the code behaves.


On Wednesday, October 7, 2015, Ola Liljedahl
> wrote:

On 23 September 2015 at 19:51, Maxim Uvarov
 wrote:



On 09/20/15 07:04, rujiacs wrote:

Signed-off-by: rujiacs 
---
helper/hash_fbk.c | 179 
helper/include/odp/helper/hash_fbk.h | 404
+++
  2 files changed, 583 insertions(+)
  create mode 100644 helper/hash_fbk.c
  create mode 100644
helper/include/odp/helper/hash_fbk.h

diff --git a/helper/hash_fbk.c
b/helper/hash_fbk.c
new file mode 100644
index 000..eae7596
--- /dev/null
+++ b/helper/hash_fbk.c
@@ -0,0 +1,179 @@
+/**
+ *   BSD LICENSE
+ *
+ *  Copyright(c) 2010-2014 Intel
Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *  Redistribution and use in source and
binary forms, with or without
+ *  modification, are permitted provided
that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code
must retain the above copyright
+ *  notice, this list of conditions and
the following disclaimer.
+ * * Redistributions in binary form
must reproduce the above copyright
+ *  notice, this list of conditions and
the following 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Bill Fischofer]

Trying to keep the rte_ prefix would be confusing.  One of the precepts of
ODP is that it doesn't preclude an application also using an underlying SDK
in addition to ODP APIs.  Whether that makes sense is up to the
application, of course.  But if ODP were to start using other prefixes I'd
imagine that would get very messy.

On Wednesday, October 7, 2015, Ola Liljedahl 
wrote:

> On 23 September 2015 at 19:51, Maxim Uvarov  > wrote:
>
>>
>>
>> On 09/20/15 07:04, rujiacs wrote:
>>
>>> Signed-off-by: rujiacs >> >
>>> ---
>>>   helper/hash_fbk.c| 179 
>>>   helper/include/odp/helper/hash_fbk.h | 404
>>> +++
>>>   2 files changed, 583 insertions(+)
>>>   create mode 100644 helper/hash_fbk.c
>>>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>>>
>>> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>>> new file mode 100644
>>> index 000..eae7596
>>> --- /dev/null
>>> +++ b/helper/hash_fbk.c
>>> @@ -0,0 +1,179 @@
>>> +/**
>>> + *   BSD LICENSE
>>> + *
>>> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>>> + *   All rights reserved.
>>> + *
>>> + *   Redistribution and use in source and binary forms, with or without
>>> + *   modification, are permitted provided that the following conditions
>>> + *   are met:
>>> + *
>>> + * * Redistributions of source code must retain the above copyright
>>> + *   notice, this list of conditions and the following disclaimer.
>>> + * * Redistributions in binary form must reproduce the above
>>> copyright
>>> + *   notice, this list of conditions and the following disclaimer in
>>> + *   the documentation and/or other materials provided with the
>>> + *   distribution.
>>> + * * Neither the name of Intel Corporation nor the names of its
>>> + *   contributors may be used to endorse or promote products derived
>>> + *   from this software without specific prior written permission.
>>> + *
>>> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
>>> FOR
>>> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
>>> COPYRIGHT
>>> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>>> INCIDENTAL,
>>> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>>> USE,
>>> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
>>> ANY
>>> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
>>> USE
>>> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>>> DAMAGE.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +#include "odph_debug.h"
>>> +#include 
>>> +
>>> +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
>>> +static odp_rwlock_t fbk_hash_lock;
>>> +
>>> +void
>>> +odp_fbk_hash_list_init()
>>> +{
>>> +TAILQ_INIT(_hash_list);
>>> +odp_rwlock_init(_hash_lock);
>>> +}
>>> +
>>> +/**
>>> + * Performs a lookup for an existing hash table, and returns a pointer
>>> to
>>> + * the table if found.
>>> + *
>>> + * @param name
>>> + *   Name of the hash table to find
>>> + *
>>> + * @return
>>> + *   pointer to hash table structure or NULL on error.
>>> + */
>>> +struct odp_fbk_hash_table *
>>> +odp_fbk_hash_find_existing(const char *name)
>>> +{
>>> +   struct odp_fbk_hash_table *h = NULL;
>>> +
>>> +odp_rwlock_read_lock(_hash_lock);
>>> +   TAILQ_FOREACH(h, _hash_list, next) {
>>> +   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
>>> +   break;
>>> +   }
>>> +   odp_rwlock_read_unlock(_hash_lock);
>>> +   if (h == NULL) {
>>> +   return NULL;
>>> +   }
>>> +   return h;
>>>
>> simple return h. (if it's NULL, NULL will be returned.)
>>
>>
>>
>> +}
>>> +
>>> +/**
>>> + * Create a new hash table for use with four byte keys.
>>> + *
>>> + * @param params
>>> + *   Parameters used in creation of hash table.
>>> + *
>>> + * @return
>>> + *   Pointer to hash table structure that is used in future hash table
>>> + *   operations, or NULL on error.
>>> + */
>>> +struct odp_fbk_hash_table *
>>> +odp_fbk_hash_create(const struct odp_fbk_hash_params *params)
>>> +{
>>> +   struct odp_fbk_hash_table *ht = NULL;
>>> +odp_shm_t shm;
>>> +   char hash_name[ODP_FBK_HASH_NAMESIZE];
>>> +   const uint32_t mem_size =
>>> +   sizeof(*ht) + (sizeof(ht->t[0]) *
>>> params->entries);

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[HePeng]

So we should change the code into ODP conventions, and resubmit in a v2?


> 在 2015年10月8日，下午4:25，Mike Holmes  写道：
> 
> http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html
>  
> 
> Api guide states what you say bill, 
> On Oct 8, 2015 4:02 AM, "Bill Fischofer"  > wrote:
> >
> > Trying to keep the rte_ prefix would be confusing.  One of the precepts of 
> > ODP is that it doesn't preclude an application also using an underlying SDK 
> > in addition to ODP APIs.  Whether that makes sense is up to the 
> > application, of course.  But if ODP were to start using other prefixes I'd 
> > imagine that would get very messy.
> 
> http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html
>  
> 
> We prohibited other prefixes
> 
> >
> > On Wednesday, October 7, 2015, Ola Liljedahl  > > wrote:
> >>
> >> On 23 September 2015 at 19:51, Maxim Uvarov  >> > wrote:
> >>>
> >>>
> >>>
> >>> On 09/20/15 07:04, rujiacs wrote:
> 
>  Signed-off-by: rujiacs >
>  ---
>    helper/hash_fbk.c| 179 
>    helper/include/odp/helper/hash_fbk.h | 404 
>  +++
>    2 files changed, 583 insertions(+)
>    create mode 100644 helper/hash_fbk.c
>    create mode 100644 helper/include/odp/helper/hash_fbk.h
> 
>  diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>  new file mode 100644
>  index 000..eae7596
>  --- /dev/null
>  +++ b/helper/hash_fbk.c
>  @@ -0,0 +1,179 @@
>  +/**
>  + *   BSD LICENSE
>  + *
>  + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>  + *   All rights reserved.
>  + *
>  + *   Redistribution and use in source and binary forms, with or without
>  + *   modification, are permitted provided that the following conditions
>  + *   are met:
>  + *
>  + * * Redistributions of source code must retain the above copyright
>  + *   notice, this list of conditions and the following disclaimer.
>  + * * Redistributions in binary form must reproduce the above 
>  copyright
>  + *   notice, this list of conditions and the following disclaimer in
>  + *   the documentation and/or other materials provided with the
>  + *   distribution.
>  + * * Neither the name of Intel Corporation nor the names of its
>  + *   contributors may be used to endorse or promote products derived
>  + *   from this software without specific prior written permission.
>  + *
>  + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>  + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>  + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 
>  FOR
>  + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
>  COPYRIGHT
>  + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
>  INCIDENTAL,
>  + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>  + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF 
>  USE,
>  + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
>  ANY
>  + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>  + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
>  USE
>  + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
>  DAMAGE.
>  + */
>  +
>  +#include 
>  +#include 
>  +#include 
>  +#include 
>  +#include 
>  +
>  +#include 
>  +#include 
>  +#include "odph_debug.h"
>  +#include 
>  +
>  +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
>  +static odp_rwlock_t fbk_hash_lock;
>  +
>  +void
>  +odp_fbk_hash_list_init()
>  +{
>  +TAILQ_INIT(_hash_list);
>  +odp_rwlock_init(_hash_lock);
>  +}
>  +
>  +/**
>  + * Performs a lookup for an existing hash table, and returns a pointer 
>  to
>  + * the table if found.
>  + *
>  + * @param name
>  + *   Name of the hash table to find
>  + *
>  + * @return
>  + *   pointer to hash table structure or NULL on error.
>  + */
>  +struct odp_fbk_hash_table *
>  +odp_fbk_hash_find_existing(const char *name)
>  +{
>  +   struct odp_fbk_hash_table *h = NULL;
>  +
>  +odp_rwlock_read_lock(_hash_lock);
>  +   

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Mike Holmes]

On Oct 8, 2015 5:20 AM, "HePeng"  wrote:
>
> So we should change the code into ODP conventions, and resubmit in a v2?
>

Yes.

I would  check that there are no more api changes suggested by anyone that
need discussion first. With that if checkpatch is clean and each patch can
be applied without breaking  the build it is good for a v2.

It will be checked with the check-odp tools which  you can run locally to
be sure it is basically  acceptable.

>
>> 在 2015年10月8日，下午4:25，Mike Holmes  写道：
>>
>>
http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html
>>
>> Api guide states what you say bill,
>> On Oct 8, 2015 4:02 AM, "Bill Fischofer" 
wrote:
>> >
>> > Trying to keep the rte_ prefix would be confusing.  One of the
precepts of ODP is that it doesn't preclude an application also using an
underlying SDK in addition to ODP APIs.  Whether that makes sense is up to
the application, of course.  But if ODP were to start using other prefixes
I'd imagine that would get very messy.
>>
>>
http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html
>>
>> We prohibited other prefixes
>>
>> >
>> > On Wednesday, October 7, 2015, Ola Liljedahl 
wrote:
>> >>
>> >> On 23 September 2015 at 19:51, Maxim Uvarov 
wrote:
>> >>>
>> >>>
>> >>>
>> >>> On 09/20/15 07:04, rujiacs wrote:
>> 
>>  Signed-off-by: rujiacs 
>>  ---
>>    helper/hash_fbk.c| 179 
>>    helper/include/odp/helper/hash_fbk.h | 404
+++
>>    2 files changed, 583 insertions(+)
>>    create mode 100644 helper/hash_fbk.c
>>    create mode 100644 helper/include/odp/helper/hash_fbk.h
>> 
>>  diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>>  new file mode 100644
>>  index 000..eae7596
>>  --- /dev/null
>>  +++ b/helper/hash_fbk.c
>>  @@ -0,0 +1,179 @@
>>  +/**
>>  + *   BSD LICENSE
>>  + *
>>  + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>>  + *   All rights reserved.
>>  + *
>>  + *   Redistribution and use in source and binary forms, with or
without
>>  + *   modification, are permitted provided that the following
conditions
>>  + *   are met:
>>  + *
>>  + * * Redistributions of source code must retain the above
copyright
>>  + *   notice, this list of conditions and the following
disclaimer.
>>  + * * Redistributions in binary form must reproduce the above
copyright
>>  + *   notice, this list of conditions and the following
disclaimer in
>>  + *   the documentation and/or other materials provided with the
>>  + *   distribution.
>>  + * * Neither the name of Intel Corporation nor the names of its
>>  + *   contributors may be used to endorse or promote products
derived
>>  + *   from this software without specific prior written
permission.
>>  + *
>>  + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS
>>  + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
NOT
>>  + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR
>>  + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT
>>  + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
>>  + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT
>>  + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE,
>>  + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY
>>  + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT
>>  + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
>>  + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
>>  + */
>>  +
>>  +#include 
>>  +#include 
>>  +#include 
>>  +#include 
>>  +#include 
>>  +
>>  +#include 
>>  +#include 
>>  +#include "odph_debug.h"
>>  +#include 
>>  +
>>  +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
>>  +static odp_rwlock_t fbk_hash_lock;
>>  +
>>  +void
>>  +odp_fbk_hash_list_init()
>>  +{
>>  +TAILQ_INIT(_hash_list);
>>  +odp_rwlock_init(_hash_lock);
>>  +}
>>  +
>>  +/**
>>  + * Performs a lookup for an existing hash table, and returns a
pointer to
>>  + * the table if found.
>>  + *
>>  + * @param name
>>  + *   Name of the hash table to find
>>  + *
>>  + * @return
>>  + *   pointer to hash table structure or NULL on error.
>>  + */
>>  +struct odp_fbk_hash_table *
>>  +odp_fbk_hash_find_existing(const char *name)
>>  +{
>>  +   struct odp_fbk_hash_table *h = NULL;
>> 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Mike Holmes]

http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html

Api guide states what you say bill,
On Oct 8, 2015 4:02 AM, "Bill Fischofer"  wrote:
>
> Trying to keep the rte_ prefix would be confusing.  One of the precepts
of ODP is that it doesn't preclude an application also using an underlying
SDK in addition to ODP APIs.  Whether that makes sense is up to the
application, of course.  But if ODP were to start using other prefixes I'd
imagine that would get very messy.

http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html

We prohibited other prefixes

>
> On Wednesday, October 7, 2015, Ola Liljedahl 
wrote:
>>
>> On 23 September 2015 at 19:51, Maxim Uvarov 
wrote:
>>>
>>>
>>>
>>> On 09/20/15 07:04, rujiacs wrote:

 Signed-off-by: rujiacs 
 ---
   helper/hash_fbk.c| 179 
   helper/include/odp/helper/hash_fbk.h | 404
+++
   2 files changed, 583 insertions(+)
   create mode 100644 helper/hash_fbk.c
   create mode 100644 helper/include/odp/helper/hash_fbk.h

 diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
 new file mode 100644
 index 000..eae7596
 --- /dev/null
 +++ b/helper/hash_fbk.c
 @@ -0,0 +1,179 @@
 +/**
 + *   BSD LICENSE
 + *
 + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
 + *   All rights reserved.
 + *
 + *   Redistribution and use in source and binary forms, with or
without
 + *   modification, are permitted provided that the following
conditions
 + *   are met:
 + *
 + * * Redistributions of source code must retain the above
copyright
 + *   notice, this list of conditions and the following disclaimer.
 + * * Redistributions in binary form must reproduce the above
copyright
 + *   notice, this list of conditions and the following disclaimer
in
 + *   the documentation and/or other materials provided with the
 + *   distribution.
 + * * Neither the name of Intel Corporation nor the names of its
 + *   contributors may be used to endorse or promote products
derived
 + *   from this software without specific prior written permission.
 + *
 + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS
 + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR
 + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT
 + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
 + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE,
 + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY
 + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT
 + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
 + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +#include 
 +#include "odph_debug.h"
 +#include 
 +
 +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
 +static odp_rwlock_t fbk_hash_lock;
 +
 +void
 +odp_fbk_hash_list_init()
 +{
 +TAILQ_INIT(_hash_list);
 +odp_rwlock_init(_hash_lock);
 +}
 +
 +/**
 + * Performs a lookup for an existing hash table, and returns a
pointer to
 + * the table if found.
 + *
 + * @param name
 + *   Name of the hash table to find
 + *
 + * @return
 + *   pointer to hash table structure or NULL on error.
 + */
 +struct odp_fbk_hash_table *
 +odp_fbk_hash_find_existing(const char *name)
 +{
 +   struct odp_fbk_hash_table *h = NULL;
 +
 +odp_rwlock_read_lock(_hash_lock);
 +   TAILQ_FOREACH(h, _hash_list, next) {
 +   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
 +   break;
 +   }
 +   odp_rwlock_read_unlock(_hash_lock);
 +   if (h == NULL) {
 +   return NULL;
 +   }
 +   return h;
>>>
>>> simple return h. (if it's NULL, NULL will be returned.)
>>>
>>>
>>>
 +}
 +
 +/**
 + * Create a new hash table for use with four byte keys.
 + *
 + * @param params
 + *   Parameters used in creation of hash table.
 + *
 + * @return
 + *   Pointer to hash table structure that is used in future hash table
 + *   operations, or NULL on error.
 + */
 +struct odp_fbk_hash_table *
 +odp_fbk_hash_create(const 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Mike Holmes]

On 8 October 2015 at 13:13, Ola Liljedahl  wrote:

> On 8 October 2015 at 10:02, Bill Fischofer 
> wrote:
>
>> Trying to keep the rte_ prefix would be confusing.  One of the precepts
>> of ODP is that it doesn't preclude an application also using an underlying
>> SDK in addition to ODP APIs.  Whether that makes sense is up to the
>> application, of course.  But if ODP were to start using other prefixes I'd
>> imagine that would get very messy.
>
> It would also be confusing to have functions that use odp_ naming
> conventions but don't behave like ODP functions (with regards to e.g.
> handling and returning errors or checking parameters).
>
> So if we rename code imported from e.g. DPDK, we should also convert it to
> behave like proper ODP functions. That we can base the implementation on
> preexisting code is just incidental and should not affect how the code
> behaves.
>

agree

>
>
>> On Wednesday, October 7, 2015, Ola Liljedahl 
>> wrote:
>>
>>> On 23 September 2015 at 19:51, Maxim Uvarov 
>>> wrote:
>>>


 On 09/20/15 07:04, rujiacs wrote:

> Signed-off-by: rujiacs 
> ---
>   helper/hash_fbk.c| 179 
>   helper/include/odp/helper/hash_fbk.h | 404
> +++
>   2 files changed, 583 insertions(+)
>   create mode 100644 helper/hash_fbk.c
>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>
> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
> new file mode 100644
> index 000..eae7596
> --- /dev/null
> +++ b/helper/hash_fbk.c
> @@ -0,0 +1,179 @@
> +/**
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> + *   All rights reserved.
> + *
> + *   Redistribution and use in source and binary forms, with or
> without
> + *   modification, are permitted provided that the following
> conditions
> + *   are met:
> + *
> + * * Redistributions of source code must retain the above
> copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above
> copyright
> + *   notice, this list of conditions and the following disclaimer
> in
> + *   the documentation and/or other materials provided with the
> + *   distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + *   contributors may be used to endorse or promote products
> derived
> + *   from this software without specific prior written permission.
> + *
> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> USE,
> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> ON ANY
> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include "odph_debug.h"
> +#include 
> +
> +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
> +static odp_rwlock_t fbk_hash_lock;
> +
> +void
> +odp_fbk_hash_list_init()
> +{
> +TAILQ_INIT(_hash_list);
> +odp_rwlock_init(_hash_lock);
> +}
> +
> +/**
> + * Performs a lookup for an existing hash table, and returns a
> pointer to
> + * the table if found.
> + *
> + * @param name
> + *   Name of the hash table to find
> + *
> + * @return
> + *   pointer to hash table structure or NULL on error.
> + */
> +struct odp_fbk_hash_table *
> +odp_fbk_hash_find_existing(const char *name)
> +{
> +   struct odp_fbk_hash_table *h = NULL;
> +
> +odp_rwlock_read_lock(_hash_lock);
> +   TAILQ_FOREACH(h, _hash_list, next) {
> +   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
> +   break;
> +   }
> +   odp_rwlock_read_unlock(_hash_lock);
> +   if (h == NULL) {
> +   return 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[HePeng]

There are some discussion about moving the crc into the ODP APIs. 
see the thread [lng-odp] [PATCH 1/5] Add Jhash and CRC functions





> 在 2015年10月8日，下午5:27，Mike Holmes  写道：
> 
> 
> On Oct 8, 2015 5:20 AM, "HePeng"  > wrote:
> >
> > So we should change the code into ODP conventions, and resubmit in a v2?
> >
> 
> Yes.
> 
> I would  check that there are no more api changes suggested by anyone that 
> need discussion first. With that if checkpatch is clean and each patch can be 
> applied without breaking  the build it is good for a v2.
> 
> It will be checked with the check-odp tools which  you can run locally to be 
> sure it is basically  acceptable.
> 
> >
> >> 在 2015年10月8日，下午4:25，Mike Holmes  >> > 写道：
> >>
> >> http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html
> >>  
> >> 
> >>
> >> Api guide states what you say bill, 
> >> On Oct 8, 2015 4:02 AM, "Bill Fischofer"  >> > wrote:
> >> >
> >> > Trying to keep the rte_ prefix would be confusing.  One of the precepts 
> >> > of ODP is that it doesn't preclude an application also using an 
> >> > underlying SDK in addition to ODP APIs.  Whether that makes sense is up 
> >> > to the application, of course.  But if ODP were to start using other 
> >> > prefixes I'd imagine that would get very messy.
> >>
> >> http://docs.opendataplane.org/master/linux-generic-doxygen-html/api_guide_lines.html
> >>  
> >> 
> >>
> >> We prohibited other prefixes
> >>
> >> >
> >> > On Wednesday, October 7, 2015, Ola Liljedahl  >> > > wrote:
> >> >>
> >> >> On 23 September 2015 at 19:51, Maxim Uvarov  >> >> > wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> On 09/20/15 07:04, rujiacs wrote:
> >> 
> >>  Signed-off-by: rujiacs >
> >>  ---
> >>    helper/hash_fbk.c| 179 
> >>    helper/include/odp/helper/hash_fbk.h | 404 
> >>  +++
> >>    2 files changed, 583 insertions(+)
> >>    create mode 100644 helper/hash_fbk.c
> >>    create mode 100644 helper/include/odp/helper/hash_fbk.h
> >> 
> >>  diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
> >>  new file mode 100644
> >>  index 000..eae7596
> >>  --- /dev/null
> >>  +++ b/helper/hash_fbk.c
> >>  @@ -0,0 +1,179 @@
> >>  +/**
> >>  + *   BSD LICENSE
> >>  + *
> >>  + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> >>  + *   All rights reserved.
> >>  + *
> >>  + *   Redistribution and use in source and binary forms, with or 
> >>  without
> >>  + *   modification, are permitted provided that the following 
> >>  conditions
> >>  + *   are met:
> >>  + *
> >>  + * * Redistributions of source code must retain the above 
> >>  copyright
> >>  + *   notice, this list of conditions and the following 
> >>  disclaimer.
> >>  + * * Redistributions in binary form must reproduce the above 
> >>  copyright
> >>  + *   notice, this list of conditions and the following 
> >>  disclaimer in
> >>  + *   the documentation and/or other materials provided with the
> >>  + *   distribution.
> >>  + * * Neither the name of Intel Corporation nor the names of its
> >>  + *   contributors may be used to endorse or promote products 
> >>  derived
> >>  + *   from this software without specific prior written 
> >>  permission.
> >>  + *
> >>  + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
> >>  CONTRIBUTORS
> >>  + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT 
> >>  NOT
> >>  + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 
> >>  FITNESS FOR
> >>  + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
> >>  COPYRIGHT
> >>  + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
> >>  INCIDENTAL,
> >>  + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> >>  + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS 
> >>  OF USE,
> >>  + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND 
> >>  ON ANY
> >>  + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 
> >>  TORT
> >>  + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF 
> >>  THE USE
> >>  + *   OF THIS SOFTWARE, EVEN IF 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Ola Liljedahl]

On 8 October 2015 at 10:02, Bill Fischofer 
wrote:

> Trying to keep the rte_ prefix would be confusing.  One of the precepts of
> ODP is that it doesn't preclude an application also using an underlying SDK
> in addition to ODP APIs.  Whether that makes sense is up to the
> application, of course.  But if ODP were to start using other prefixes I'd
> imagine that would get very messy.

It would also be confusing to have functions that use odp_ naming
conventions but don't behave like ODP functions (with regards to e.g.
handling and returning errors or checking parameters).

So if we rename code imported from e.g. DPDK, we should also convert it to
behave like proper ODP functions. That we can base the implementation on
preexisting code is just incidental and should not affect how the code
behaves.


> On Wednesday, October 7, 2015, Ola Liljedahl 
> wrote:
>
>> On 23 September 2015 at 19:51, Maxim Uvarov 
>> wrote:
>>
>>>
>>>
>>> On 09/20/15 07:04, rujiacs wrote:
>>>
 Signed-off-by: rujiacs 
 ---
   helper/hash_fbk.c| 179 
   helper/include/odp/helper/hash_fbk.h | 404
 +++
   2 files changed, 583 insertions(+)
   create mode 100644 helper/hash_fbk.c
   create mode 100644 helper/include/odp/helper/hash_fbk.h

 diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
 new file mode 100644
 index 000..eae7596
 --- /dev/null
 +++ b/helper/hash_fbk.c
 @@ -0,0 +1,179 @@
 +/**
 + *   BSD LICENSE
 + *
 + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
 + *   All rights reserved.
 + *
 + *   Redistribution and use in source and binary forms, with or without
 + *   modification, are permitted provided that the following conditions
 + *   are met:
 + *
 + * * Redistributions of source code must retain the above copyright
 + *   notice, this list of conditions and the following disclaimer.
 + * * Redistributions in binary form must reproduce the above
 copyright
 + *   notice, this list of conditions and the following disclaimer
 in
 + *   the documentation and/or other materials provided with the
 + *   distribution.
 + * * Neither the name of Intel Corporation nor the names of its
 + *   contributors may be used to endorse or promote products
 derived
 + *   from this software without specific prior written permission.
 + *
 + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
 CONTRIBUTORS
 + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 FOR
 + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
 COPYRIGHT
 + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 INCIDENTAL,
 + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 USE,
 + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
 ANY
 + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
 TORT
 + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
 USE
 + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
 DAMAGE.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +#include 
 +#include "odph_debug.h"
 +#include 
 +
 +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
 +static odp_rwlock_t fbk_hash_lock;
 +
 +void
 +odp_fbk_hash_list_init()
 +{
 +TAILQ_INIT(_hash_list);
 +odp_rwlock_init(_hash_lock);
 +}
 +
 +/**
 + * Performs a lookup for an existing hash table, and returns a pointer
 to
 + * the table if found.
 + *
 + * @param name
 + *   Name of the hash table to find
 + *
 + * @return
 + *   pointer to hash table structure or NULL on error.
 + */
 +struct odp_fbk_hash_table *
 +odp_fbk_hash_find_existing(const char *name)
 +{
 +   struct odp_fbk_hash_table *h = NULL;
 +
 +odp_rwlock_read_lock(_hash_lock);
 +   TAILQ_FOREACH(h, _hash_list, next) {
 +   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
 +   break;
 +   }
 +   odp_rwlock_read_unlock(_hash_lock);
 +   if (h == NULL) {
 +   return NULL;
 +   }
 +   return h;

>>> simple return h. (if it's NULL, NULL will be returned.)
>>>
>>>
>>>
>>> +}
 +
 +/**
 + * Create a new hash table for use with four byte keys.
 + *
 + * @param params
 + *   

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Bill Fischofer]

Agree.  Worth updating the API guidelines to cover this as code import from
other open source projects will likely increase over time.

On Thursday, October 8, 2015, Mike Holmes  wrote:

>
>
> On 8 October 2015 at 13:13, Ola Liljedahl  > wrote:
>
>> On 8 October 2015 at 10:02, Bill Fischofer > > wrote:
>>
>>> Trying to keep the rte_ prefix would be confusing.  One of the precepts
>>> of ODP is that it doesn't preclude an application also using an underlying
>>> SDK in addition to ODP APIs.  Whether that makes sense is up to the
>>> application, of course.  But if ODP were to start using other prefixes I'd
>>> imagine that would get very messy.
>>
>> It would also be confusing to have functions that use odp_ naming
>> conventions but don't behave like ODP functions (with regards to e.g.
>> handling and returning errors or checking parameters).
>>
>> So if we rename code imported from e.g. DPDK, we should also convert it
>> to behave like proper ODP functions. That we can base the implementation on
>> preexisting code is just incidental and should not affect how the code
>> behaves.
>>
>
> agree
>
>>
>>
>>> On Wednesday, October 7, 2015, Ola Liljedahl >> > wrote:
>>>
 On 23 September 2015 at 19:51, Maxim Uvarov 
 wrote:

>
>
> On 09/20/15 07:04, rujiacs wrote:
>
>> Signed-off-by: rujiacs 
>> ---
>>   helper/hash_fbk.c| 179 
>>   helper/include/odp/helper/hash_fbk.h | 404
>> +++
>>   2 files changed, 583 insertions(+)
>>   create mode 100644 helper/hash_fbk.c
>>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>>
>> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>> new file mode 100644
>> index 000..eae7596
>> --- /dev/null
>> +++ b/helper/hash_fbk.c
>> @@ -0,0 +1,179 @@
>> +/**
>> + *   BSD LICENSE
>> + *
>> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>> + *   All rights reserved.
>> + *
>> + *   Redistribution and use in source and binary forms, with or
>> without
>> + *   modification, are permitted provided that the following
>> conditions
>> + *   are met:
>> + *
>> + * * Redistributions of source code must retain the above
>> copyright
>> + *   notice, this list of conditions and the following
>> disclaimer.
>> + * * Redistributions in binary form must reproduce the above
>> copyright
>> + *   notice, this list of conditions and the following
>> disclaimer in
>> + *   the documentation and/or other materials provided with the
>> + *   distribution.
>> + * * Neither the name of Intel Corporation nor the names of its
>> + *   contributors may be used to endorse or promote products
>> derived
>> + *   from this software without specific prior written
>> permission.
>> + *
>> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>> CONTRIBUTORS
>> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
>> NOT
>> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
>> FITNESS FOR
>> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
>> COPYRIGHT
>> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>> INCIDENTAL,
>> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
>> OF USE,
>> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>> ON ANY
>> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
>> TORT
>> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
>> THE USE
>> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>> DAMAGE.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include "odph_debug.h"
>> +#include 
>> +
>> +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
>> +static odp_rwlock_t fbk_hash_lock;
>> +
>> +void
>> +odp_fbk_hash_list_init()
>> +{
>> +TAILQ_INIT(_hash_list);
>> +odp_rwlock_init(_hash_lock);
>> +}
>> +
>> +/**
>> + * Performs a lookup for an existing hash table, and returns a
>> pointer to
>> + * the table if found.
>> + *
>> + * @param name
>> + *   Name of the hash table to find
>> + *
>> + * @return
>> + *   pointer 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[HePeng]

> 在 2015年10月8日，下午8:13，Ola Liljedahl  写道：
> 
> On 8 October 2015 at 10:02, Bill Fischofer  > wrote:
> Trying to keep the rte_ prefix would be confusing.  One of the precepts of 
> ODP is that it doesn't preclude an application also using an underlying SDK 
> in addition to ODP APIs.  Whether that makes sense is up to the application, 
> of course.  But if ODP were to start using other prefixes I'd imagine that 
> would get very messy.
> It would also be confusing to have functions that use odp_ naming conventions 
> but don't behave like ODP functions (with regards to e.g. handling and 
> returning errors or checking parameters).
We can fix this by wrapping these functions.
 But considering that the internal code is already ready, I am thinking reserve 
the code of *static* functions (internal implementations)?



> 
> So if we rename code imported from e.g. DPDK, we should also convert it to 
> behave like proper ODP functions. That we can base the implementation on 
> preexisting code is just incidental and should not affect how the code 
> behaves.
> 
> 
> On Wednesday, October 7, 2015, Ola Liljedahl  > wrote:
> On 23 September 2015 at 19:51, Maxim Uvarov > 
> wrote:
> 
> 
> On 09/20/15 07:04, rujiacs wrote:
> Signed-off-by: rujiacs >
> ---
>   helper/hash_fbk.c| 179 
>   helper/include/odp/helper/hash_fbk.h | 404 
> +++
>   2 files changed, 583 insertions(+)
>   create mode 100644 helper/hash_fbk.c
>   create mode 100644 helper/include/odp/helper/hash_fbk.h
> 
> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
> new file mode 100644
> index 000..eae7596
> --- /dev/null
> +++ b/helper/hash_fbk.c
> @@ -0,0 +1,179 @@
> +/**
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> + *   All rights reserved.
> + *
> + *   Redistribution and use in source and binary forms, with or without
> + *   modification, are permitted provided that the following conditions
> + *   are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + *   notice, this list of conditions and the following disclaimer in
> + *   the documentation and/or other materials provided with the
> + *   distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + *   contributors may be used to endorse or promote products derived
> + *   from this software without specific prior written permission.
> + *
> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include "odph_debug.h"
> +#include 
> +
> +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
> +static odp_rwlock_t fbk_hash_lock;
> +
> +void
> +odp_fbk_hash_list_init()
> +{
> +TAILQ_INIT(_hash_list);
> +odp_rwlock_init(_hash_lock);
> +}
> +
> +/**
> + * Performs a lookup for an existing hash table, and returns a pointer to
> + * the table if found.
> + *
> + * @param name
> + *   Name of the hash table to find
> + *
> + * @return
> + *   pointer to hash table structure or NULL on error.
> + */
> +struct odp_fbk_hash_table *
> +odp_fbk_hash_find_existing(const char *name)
> +{
> +   struct odp_fbk_hash_table *h = NULL;
> +
> +odp_rwlock_read_lock(_hash_lock);
> +   TAILQ_FOREACH(h, _hash_list, next) {
> +   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
> +   break;
> +   }
> +   odp_rwlock_read_unlock(_hash_lock);
> +   if (h == NULL) {
> +   return NULL;
> +   }
> +   return h;
> simple return h. (if it's NULL, NULL will be returned.)
> 
> 
> 
> +}
> +
> +/**
> + * Create a new hash table for use with four byte keys.
> + *
> + * @param params
> + *   Parameters used in 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Ola Liljedahl]

On 23 September 2015 at 19:51, Maxim Uvarov  wrote:

>
>
> On 09/20/15 07:04, rujiacs wrote:
>
>> Signed-off-by: rujiacs 
>> ---
>>   helper/hash_fbk.c| 179 
>>   helper/include/odp/helper/hash_fbk.h | 404
>> +++
>>   2 files changed, 583 insertions(+)
>>   create mode 100644 helper/hash_fbk.c
>>   create mode 100644 helper/include/odp/helper/hash_fbk.h
>>
>> diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
>> new file mode 100644
>> index 000..eae7596
>> --- /dev/null
>> +++ b/helper/hash_fbk.c
>> @@ -0,0 +1,179 @@
>> +/**
>> + *   BSD LICENSE
>> + *
>> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>> + *   All rights reserved.
>> + *
>> + *   Redistribution and use in source and binary forms, with or without
>> + *   modification, are permitted provided that the following conditions
>> + *   are met:
>> + *
>> + * * Redistributions of source code must retain the above copyright
>> + *   notice, this list of conditions and the following disclaimer.
>> + * * Redistributions in binary form must reproduce the above
>> copyright
>> + *   notice, this list of conditions and the following disclaimer in
>> + *   the documentation and/or other materials provided with the
>> + *   distribution.
>> + * * Neither the name of Intel Corporation nor the names of its
>> + *   contributors may be used to endorse or promote products derived
>> + *   from this software without specific prior written permission.
>> + *
>> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
>> FOR
>> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>> INCIDENTAL,
>> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>> USE,
>> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
>> ANY
>> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
>> USE
>> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include "odph_debug.h"
>> +#include 
>> +
>> +static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
>> +static odp_rwlock_t fbk_hash_lock;
>> +
>> +void
>> +odp_fbk_hash_list_init()
>> +{
>> +TAILQ_INIT(_hash_list);
>> +odp_rwlock_init(_hash_lock);
>> +}
>> +
>> +/**
>> + * Performs a lookup for an existing hash table, and returns a pointer to
>> + * the table if found.
>> + *
>> + * @param name
>> + *   Name of the hash table to find
>> + *
>> + * @return
>> + *   pointer to hash table structure or NULL on error.
>> + */
>> +struct odp_fbk_hash_table *
>> +odp_fbk_hash_find_existing(const char *name)
>> +{
>> +   struct odp_fbk_hash_table *h = NULL;
>> +
>> +odp_rwlock_read_lock(_hash_lock);
>> +   TAILQ_FOREACH(h, _hash_list, next) {
>> +   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
>> +   break;
>> +   }
>> +   odp_rwlock_read_unlock(_hash_lock);
>> +   if (h == NULL) {
>> +   return NULL;
>> +   }
>> +   return h;
>>
> simple return h. (if it's NULL, NULL will be returned.)
>
>
>
> +}
>> +
>> +/**
>> + * Create a new hash table for use with four byte keys.
>> + *
>> + * @param params
>> + *   Parameters used in creation of hash table.
>> + *
>> + * @return
>> + *   Pointer to hash table structure that is used in future hash table
>> + *   operations, or NULL on error.
>> + */
>> +struct odp_fbk_hash_table *
>> +odp_fbk_hash_create(const struct odp_fbk_hash_params *params)
>> +{
>> +   struct odp_fbk_hash_table *ht = NULL;
>> +odp_shm_t shm;
>> +   char hash_name[ODP_FBK_HASH_NAMESIZE];
>> +   const uint32_t mem_size =
>> +   sizeof(*ht) + (sizeof(ht->t[0]) *
>> params->entries);
>> +   uint32_t i;
>> +
>> +   /* Error checking of parameters. */
>> +   if ((!odp_is_power_of_2(params->entries)) ||
>> +   (!odp_is_power_of_2(params->entries_per_bucket))
>> ||
>> +   (params->entries == 0) ||
>> +   (params->entries_per_bucket == 0) ||
>> +   (params->entries_per_bucket > params->entries) ||
>> +   (params->entries > ODP_FBK_HASH_ENTRIES_MAX) ||
>>
>
> ODP_FBK_HASH_ENTRIES_MAX has to have ODOH_  prefix if the goal is to put
> it to helpers.
>
> +   (params->entries_per_bucket >
>> 

Re: [lng-odp] [PATCH 5/8] add fbk hash table

[Maxim Uvarov]

On 09/20/15 07:04, rujiacs wrote:

Signed-off-by: rujiacs 
---
  helper/hash_fbk.c| 179 
  helper/include/odp/helper/hash_fbk.h | 404 +++
  2 files changed, 583 insertions(+)
  create mode 100644 helper/hash_fbk.c
  create mode 100644 helper/include/odp/helper/hash_fbk.h

diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
new file mode 100644
index 000..eae7596
--- /dev/null
+++ b/helper/hash_fbk.c
@@ -0,0 +1,179 @@
+/**
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "odph_debug.h"
+#include 
+
+static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
+static odp_rwlock_t fbk_hash_lock;
+
+void
+odp_fbk_hash_list_init()
+{
+TAILQ_INIT(_hash_list);
+odp_rwlock_init(_hash_lock);
+}
+
+/**
+ * Performs a lookup for an existing hash table, and returns a pointer to
+ * the table if found.
+ *
+ * @param name
+ *   Name of the hash table to find
+ *
+ * @return
+ *   pointer to hash table structure or NULL on error.
+ */
+struct odp_fbk_hash_table *
+odp_fbk_hash_find_existing(const char *name)
+{
+   struct odp_fbk_hash_table *h = NULL;
+
+odp_rwlock_read_lock(_hash_lock);
+   TAILQ_FOREACH(h, _hash_list, next) {
+   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
+   break;
+   }
+   odp_rwlock_read_unlock(_hash_lock);
+   if (h == NULL) {
+   return NULL;
+   }
+   return h;

simple return h. (if it's NULL, NULL will be returned.)



+}
+
+/**
+ * Create a new hash table for use with four byte keys.
+ *
+ * @param params
+ *   Parameters used in creation of hash table.
+ *
+ * @return
+ *   Pointer to hash table structure that is used in future hash table
+ *   operations, or NULL on error.
+ */
+struct odp_fbk_hash_table *
+odp_fbk_hash_create(const struct odp_fbk_hash_params *params)
+{
+   struct odp_fbk_hash_table *ht = NULL;
+odp_shm_t shm;
+   char hash_name[ODP_FBK_HASH_NAMESIZE];
+   const uint32_t mem_size =
+   sizeof(*ht) + (sizeof(ht->t[0]) * params->entries);
+   uint32_t i;
+
+   /* Error checking of parameters. */
+   if ((!odp_is_power_of_2(params->entries)) ||
+   (!odp_is_power_of_2(params->entries_per_bucket)) ||
+   (params->entries == 0) ||
+   (params->entries_per_bucket == 0) ||
+   (params->entries_per_bucket > params->entries) ||
+   (params->entries > ODP_FBK_HASH_ENTRIES_MAX) ||


ODP_FBK_HASH_ENTRIES_MAX has to have ODOH_  prefix if the goal is to put it to 
helpers.


+   (params->entries_per_bucket > 
ODP_FBK_HASH_ENTRIES_PER_BUCKET_MAX)) {
+   return NULL;
+   }
+
+   snprintf(hash_name, sizeof(hash_name), "FBK_%s", params->name);
+
+   odp_rwlock_write_lock(_hash_lock);
+
+   /* guarantee there's no existing */
+   TAILQ_FOREACH(ht, _hash_list, next) {
+   if (strncmp(params->name, ht->name, ODP_FBK_HASH_NAMESIZE) == 0)
+   break;
+   }
+   if (ht != NULL)
+   goto exit;
+
+printf("reserve\n");

remove print.

+   

[lng-odp] [PATCH 5/8] add fbk hash table

[rujiacs]

Signed-off-by: rujiacs 
---
 helper/hash_fbk.c| 179 
 helper/include/odp/helper/hash_fbk.h | 404 +++
 2 files changed, 583 insertions(+)
 create mode 100644 helper/hash_fbk.c
 create mode 100644 helper/include/odp/helper/hash_fbk.h

diff --git a/helper/hash_fbk.c b/helper/hash_fbk.c
new file mode 100644
index 000..eae7596
--- /dev/null
+++ b/helper/hash_fbk.c
@@ -0,0 +1,179 @@
+/**
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "odph_debug.h"
+#include 
+
+static TAILQ_HEAD(, odp_fbk_hash_table) fbk_hash_list;
+static odp_rwlock_t fbk_hash_lock;
+
+void
+odp_fbk_hash_list_init()
+{
+TAILQ_INIT(_hash_list);
+odp_rwlock_init(_hash_lock);
+}
+
+/**
+ * Performs a lookup for an existing hash table, and returns a pointer to
+ * the table if found.
+ *
+ * @param name
+ *   Name of the hash table to find
+ *
+ * @return
+ *   pointer to hash table structure or NULL on error.
+ */
+struct odp_fbk_hash_table *
+odp_fbk_hash_find_existing(const char *name)
+{
+   struct odp_fbk_hash_table *h = NULL;
+
+odp_rwlock_read_lock(_hash_lock);
+   TAILQ_FOREACH(h, _hash_list, next) {
+   if (strncmp(name, h->name, ODP_FBK_HASH_NAMESIZE) == 0)
+   break;
+   }
+   odp_rwlock_read_unlock(_hash_lock);
+   if (h == NULL) {
+   return NULL;
+   }
+   return h;
+}
+
+/**
+ * Create a new hash table for use with four byte keys.
+ *
+ * @param params
+ *   Parameters used in creation of hash table.
+ *
+ * @return
+ *   Pointer to hash table structure that is used in future hash table
+ *   operations, or NULL on error.
+ */
+struct odp_fbk_hash_table *
+odp_fbk_hash_create(const struct odp_fbk_hash_params *params)
+{
+   struct odp_fbk_hash_table *ht = NULL;
+odp_shm_t shm;
+   char hash_name[ODP_FBK_HASH_NAMESIZE];
+   const uint32_t mem_size =
+   sizeof(*ht) + (sizeof(ht->t[0]) * params->entries);
+   uint32_t i;
+
+   /* Error checking of parameters. */
+   if ((!odp_is_power_of_2(params->entries)) ||
+   (!odp_is_power_of_2(params->entries_per_bucket)) ||
+   (params->entries == 0) ||
+   (params->entries_per_bucket == 0) ||
+   (params->entries_per_bucket > params->entries) ||
+   (params->entries > ODP_FBK_HASH_ENTRIES_MAX) ||
+   (params->entries_per_bucket > 
ODP_FBK_HASH_ENTRIES_PER_BUCKET_MAX)) {
+   return NULL;
+   }
+
+   snprintf(hash_name, sizeof(hash_name), "FBK_%s", params->name);
+
+   odp_rwlock_write_lock(_hash_lock);
+
+   /* guarantee there's no existing */
+   TAILQ_FOREACH(ht, _hash_list, next) {
+   if (strncmp(params->name, ht->name, ODP_FBK_HASH_NAMESIZE) == 0)
+   break;
+   }
+   if (ht != NULL)
+   goto exit;
+
+printf("reserve\n");
+   /* Allocate memory for table. */
+shm = odp_shm_reserve(hash_name, mem_size, ODP_CACHE_LINE_SIZE, 0);
+   if (shm == ODP_SHM_INVALID) {
+   ODPH_ERR("Failed to allocate fbk hash table\n");
+