On Mon, Feb 8, 2016 at 9:40 AM, Assaf Muller wrote:
> As for DVR, I'm searching for someone to pick up the gauntlet and
> contribute some L3 fullstack tests. I'd be more than happy to review
> it! I even have an abandoned patch that gets the ball rolling (The
> idea is to test
> On 09 Feb 2016, at 21:43, Sean M. Collins wrote:
>
> Kevin Benton wrote:
>> I agree with the mtu setting because there isn't much of a downside to
>> enabling it. However, the others do have reasons to be disabled.
>>
>> csum - requires runtime detection of support for a
I agree with the mtu setting because there isn't much of a downside to
enabling it. However, the others do have reasons to be disabled.
csum - requires runtime detection of support for a feature and then auto
degradation for systems that don't support it. People were against those so
we have the
Hi,
> I'm generally sympathetic to what you're saying, and I agree that we
> need to do something about disabled-by-default features, at the very
> least on the testing front. Comments in-line.
>
> On Mon, Feb 8, 2016 at 4:47 PM, Sean M. Collins wrote:
> > Hi,
> >
> > With the path_mtu
On 02/08/2016 09:47 AM, Sean M. Collins wrote:
Hi,
With the path_mtu issue - our default was to set path_mtu to zero, and
do no calculation against the physical segment MTU and the overhead for
the tunneling protocol that was selected for a tenant network. Which
means the network would break.
Hi,
With the path_mtu issue - our default was to set path_mtu to zero, and
do no calculation against the physical segment MTU and the overhead for
the tunneling protocol that was selected for a tenant network. Which
means the network would break.
I am working on patches to change our behavior to
I'm generally sympathetic to what you're saying, and I agree that we
need to do something about disabled-by-default features, at the very
least on the testing front. Comments in-line.
On Mon, Feb 8, 2016 at 4:47 PM, Sean M. Collins wrote:
> Hi,
>
> With the path_mtu issue -