Hi,
Based on the requirements from our customers, we have come across certain
limitations in the current scheduler design,
1) Creating a huge number of odp_queue_t is very expensive operation since
each queue contains a context and having millions of queues creates memory
constraints in the platf
Thanks, Bala. I like this direction. One point to discuss is the idea
of flow hashes vs. flow ids or labels. A hash is an
implementation-defined value that is derived from some
application-specified set of fields (e.g., based on tuples). A flow id
or label is an application-chosen value that is use
On 6 April 2018 at 20:56, Bill Fischofer wrote:
> Thanks, Bala. I like this direction. One point to discuss is the idea
> of flow hashes vs. flow ids or labels. A hash is an
> implementation-defined value that is derived from some
> application-specified set of fields (e.g., based on tuples). A f
In the case of DPI, I came across this.
Did you consider :
- a symetric hash option so that uplink and downlink packets of a single
flow (either TCP or UDP) give the same hash value?
- an offset so that HW calculates the hash starting at a specific packet
area?
- an option that would calculate th
On 6 April 2018 at 22:07, Francois Ozog wrote:
> In the case of DPI, I came across this.
>
> Did you consider :
> - a symetric hash option so that uplink and downlink packets of a single
> flow (either TCP or UDP) give the same hash value?
> - an offset so that HW calculates the hash starting at
On Fri, Apr 6, 2018 at 12:12 PM, Francois Ozog
wrote:
>
>
> On 6 April 2018 at 19:02, Bill Fischofer
> wrote:
>
>>
>>
>> On Fri, Apr 6, 2018 at 11:37 AM, Francois Ozog
>> wrote:
>>
>>> In the case of DPI, I came across this.
>>>
>>> Did you consider :
>>> - a symetric hash option so that uplin