On Wed, Mar 30, 2016 at 09:04:03PM +, Mark McKinstry wrote:
> I've tested this patch in our scenario and I can confirm that it still
> fixes all of our issues.
I've applied the patch to the ipsec tree now.
Thanks for testing!
--
To unsubscribe from this list: send the line "unsubscribe linux-
I've tested this patch in our scenario and I can confirm that it still
fixes all of our issues.
On 22/03/16 23:53, Steffen Klassert wrote:
> On Tue, Mar 15, 2016 at 01:28:01PM +0100, Steffen Klassert wrote:
>> On Mon, Mar 14, 2016 at 09:52:05PM +, Mark McKinstry wrote:
>>> Your patch adds a d
On Tue, Mar 15, 2016 at 01:28:01PM +0100, Steffen Klassert wrote:
> On Mon, Mar 14, 2016 at 09:52:05PM +, Mark McKinstry wrote:
> > Your patch adds a dst_release() call to my suggested fix, but this is
> > problematic because the kfree_skb() call at tx_error already takes care
> > of releasin
On Mon, Mar 14, 2016 at 09:52:05PM +, Mark McKinstry wrote:
> Your patch adds a dst_release() call to my suggested fix, but this is
> problematic because the kfree_skb() call at tx_error already takes care
> of releasing dst - via kfree_skb() > __kfree_skb() > skb_release_all() >
> skb_relea
On 04/03/16 20:05, Steffen Klassert wrote:
> On Wed, Feb 24, 2016 at 09:37:39PM +, Mark McKinstry wrote:
>> On 19/02/16 01:19, Steffen Klassert wrote:
>>> On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
This patch fixes our issue, thanks. In our scenario the tunnel path MTU
On Wed, Feb 24, 2016 at 09:37:39PM +, Mark McKinstry wrote:
> On 19/02/16 01:19, Steffen Klassert wrote:
> > On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
> >> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
> >> now gets updated so that subsequent larg
On Wed, Feb 24, 2016 at 09:37:39PM +, Mark McKinstry wrote:
> On 19/02/16 01:19, Steffen Klassert wrote:
> > On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
> >> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
> >> now gets updated so that subsequent larg
On 19/02/16 01:19, Steffen Klassert wrote:
> On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
>> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
>> now gets updated so that subsequent large packets sent over the tunnel
>> get fragmented correctly.
> I've appli
On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
> now gets updated so that subsequent large packets sent over the tunnel
> get fragmented correctly.
I've applied this patch to the ipsec tree now.
Thanks for
On 17/02/16 20:08, Steffen Klassert wrote:
> On Wed, Feb 10, 2016 at 01:50:20AM +, Mark McKinstry wrote:
>>> So this version is slightly modified to cover the IPv4 case in addition to
>>> the IPv6 case. With this patch I was able to run netperf over either an
>>> IPv4 or IPv6 address routed
On Wed, Feb 10, 2016 at 01:50:20AM +, Mark McKinstry wrote:
> >
> > So this version is slightly modified to cover the IPv4 case in addition to
> > the IPv6 case. With this patch I was able to run netperf over either an
> > IPv4 or IPv6 address routed over the ip6_vti tunnel.
> We have the same
From: Alexander Duyck
Date: Fri, 29 May 2015 11:28:26 -0700
> From: Steffen Klassert
>
> We currently rely on the PMTU discovery of xfrm.
> However if a packet is localy sent, the PMTU mechanism
> of xfrm tries to to local socket notification what
> might not work for applications like ping tha
12 matches
Mail list logo
