> On Mar 17, 2014, at 6:57 PM, Joe Stringer wrote:
>
>> On Fri, Mar 7, 2014 at 2:45 PM, Ethan Jackson wrote:
>> I'm surprised its only 10%, do you have a sense of why? Perhaps when
>> running TCP_CRR we delete the flow the first time we see it, and we
>> need to do xlate_actions() to generate
On Fri, Mar 7, 2014 at 2:45 PM, Ethan Jackson wrote:
> I'm surprised its only 10%, do you have a sense of why? Perhaps when
> running TCP_CRR we delete the flow the first time we see it, and we
> need to do xlate_actions() to generate the list of things to push
> stats to anyways? If this is wh
> Initial testing shows a modest improvement in TCP_CRR performance (~10%)
> when the switch is constantly revalidating.
I'm surprised its only 10%, do you have a sense of why? Perhaps when
running TCP_CRR we delete the flow the first time we see it, and we
need to do xlate_actions() to generate
Previously we would revalidate all flows if the "need_revalidate" flag
was raised. This patch modifies the logic to delete low throughput flows
rather than revalidate them. High-throughput flows are unaffected by
this change. This patch identifies the flows based on the number of bytes
seen since t
