Thanks, Bala. The link seems to have been corrupted in your post. The
proper link is here:
https://docs.google.com/document/d/1HDHHxSMtHNWl9_sWIVoKRaB4zdsb4hT-PKK6sUB708s/
On Thu, May 17, 2018 at 7:27 AM, Bala Manoharan
wrote:
> Hi All,
>
> Below is the initial design draft for Flow aware schedu
Hi All,
Below is the initial design draft for Flow aware scheduler.
Pls review the document and provide your valuable feedback.
https://docs.google.com/document/d/1HDHHxSMtHNWl9_
sWIVoKRaB4zdsb4hT-PKK6sUB708s/edit?usp=sharing
Regards,
Bala
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
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
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 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
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
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