On Oct 7, 2014, at 3:42 PM, Jarno Rajahalme wrote:
>
> On Oct 6, 2014, at 3:17 PM, Ben Pfaff wrote:
>
>> The new code is at least a little harder to understand. I am trying
>> to figure out whether the performance improvement outweighs that cost.
>> What is your opinion?
>
> I have not chec
On Oct 6, 2014, at 3:17 PM, Ben Pfaff wrote:
> On Thu, Oct 02, 2014 at 09:20:32AM -0700, Jarno Rajahalme wrote:
>>
>> On Sep 26, 2014, at 11:33 AM, Ben Pfaff wrote:
>>
>>> On Wed, Sep 24, 2014 at 11:24:01AM -0700, Jarno Rajahalme wrote:
Earlier I have seen the frags checking suspiciously
On Thu, Oct 02, 2014 at 09:20:32AM -0700, Jarno Rajahalme wrote:
>
> On Sep 26, 2014, at 11:33 AM, Ben Pfaff wrote:
>
> > On Wed, Sep 24, 2014 at 11:24:01AM -0700, Jarno Rajahalme wrote:
> >> Earlier I have seen the frags checking suspiciously high in perf
> >> reports, but did not understand wh
On Sep 26, 2014, at 11:33 AM, Ben Pfaff wrote:
> On Wed, Sep 24, 2014 at 11:24:01AM -0700, Jarno Rajahalme wrote:
>> Earlier I have seen the frags checking suspiciously high in perf
>> reports, but did not understand why. Maybe this explains it:
>>
>> Previously we checked frags handling befor
On Wed, Sep 24, 2014 at 11:24:01AM -0700, Jarno Rajahalme wrote:
> Earlier I have seen the frags checking suspiciously high in perf
> reports, but did not understand why. Maybe this explains it:
>
> Previously we checked frags handling before each flow table lookup.
> As the nw_frags field is not
Earlier I have seen the frags checking suspiciously high in perf
reports, but did not understand why. Maybe this explains it:
Previously we checked frags handling before each flow table lookup.
As the nw_frags field is not writeable, it suffices to check them
once, before the first table lookup.
