On Fri, May 11, 2018 at 5:19 AM, Dmitry Vyukov wrote:
> On Thu, May 10, 2018 at 12:23 PM, Dan Streetman wrote:
>>>>>>>> wrote:
>>>>>>>>> On 20.02.2018 18:26, Neil Horman wrote:
>>>>>>>>>>
>>>>>
On Thu, May 10, 2018 at 2:46 AM, Dmitry Vyukov wrote:
> On Mon, Apr 16, 2018 at 9:42 PM, Dan Streetman wrote:
>>>>>> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
>>>>>> wrote:
>>>>>>> On 20.02.2018 18:26, Neil Horman wrote:
>&g
On Mon, Apr 16, 2018 at 3:35 AM, Dmitry Vyukov wrote:
> On Fri, Apr 13, 2018 at 5:54 PM, Dmitry Vyukov wrote:
>> On Fri, Apr 13, 2018 at 2:43 PM, Dan Streetman wrote:
>>> On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote:
>>>> On Wed, Feb 21, 2018 at 3:53
On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote:
> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
> wrote:
>> On 20.02.2018 18:26, Neil Horman wrote:
>>>
>>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
wrote:
>
i?id=97811
Signed-off-by: Dan Streetman
---
include/net/net_namespace.h | 10 ++
net/ipv4/tcp.c | 3 +++
net/ipv4/tcp_timer.c| 15 +++
3 files changed, 28 insertions(+)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index f8
On Thu, Jan 26, 2017 at 1:04 PM, David Miller wrote:
> From: Florian Westphal
> Date: Thu, 26 Jan 2017 17:24:33 +0100
>
>> Eric Dumazet wrote:
>>> > Though possibly with different things not setting the "input" function
>>> > pointer in the "struct dst_entry".
>>> >
>>> > include/net/dst.h:
>>>
From: David Wragg
Allow the MTU of vxlan devices without an underlying device to be set
to larger values (up to a maximum based on IP packet limits and vxlan
overhead).
Previously, their MTUs could not be set to higher than the
conventional ethernet value of 1500. This is a very arbitrary value
From: David Wragg
Allow the MTU of geneve devices to be set to large values, in order to
exploit underlying networks with larger frame sizes.
GENEVE does not have a fixed encapsulation overhead (an openvswitch
rule can add variable length options), so there is no relevant maximum
MTU to enforce.
Can you queue these for 4.4 stable? The first 2 are cherry-picked cleanly
into 4.4, the last required only context changes to apply.
The commits are only needed in 4.4, as the bugs they fix were introduced
after 4.1.
David Wragg (3):
vxlan: Relax MTU constraints
geneve: Relax MTU constraints
From: David Wragg
Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
transmit vxlan packets of any size, constrained only by the ability to
send out the resulting packets. 4.3 introduced netdevs corresponding
to tunnel vports. These netdevs have an MTU, which limits the size
On Fri, Jun 3, 2016 at 2:44 PM, David Miller wrote:
> From: Dan Streetman
> Date: Fri, 3 Jun 2016 13:49:09 -0400
>
>> Can you queue up these commits for stable?
>
> This stuff doesn't cleanly backport, I tried several times already.
ah sorry. i'll get a b
Can you queue up these commits for stable?
commit 72564b59ffc438ea103b0727a921aaddce766728
Author: David Wragg
Date: Wed Feb 10 00:05:55 2016 +
vxlan: Relax MTU constraints
commit 55e5bfb53cff286c1c1ff49f51325dc15c7fea63
Author: David Wragg
Date: Wed Feb 10 00:05:57 2016 +
Can you queue this 3-commit patch series for stable?
7e059158d57b79159eaf1f504825d19866ef2c42 ("vxlan, gre, geneve: Set a
large MTU on ovs-created tunnel devices")
55e5bfb53cff286c1c1ff49f51325dc15c7fea63 ("geneve: Relax MTU constraints")
72564b59ffc438ea103b0727a921aaddce766728 ("vxlan: Relax MTU
Hi David,
can you queue commit c386578f1cdb4dac230395a951f88027f64346e3 for stable?
Without it, any system with > 16 cpus and a lot of ipsec use, that
leaves xfrmN_gc_thresh set to its default, will (eventually) see
failures to create new ipsec connections.
It fixes commit 703fb94ec58e0e8769380c
Hi Ariel,
I'm trying to update the bnx2x driver in Ubuntu trusty (3.13 kernel)
release to use the 7.51.10 firmware; can you help me determine which
commits need to be backported?
Some reference is in Launchpad bug 1454286:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454286
basically, t
David, can you queue commit a8a572a for stable please? It fixes
commit d7c7544c3d from 2010, and without it anyone using multiple
ipsec net namespaces can find one (or more) of their netns incorrectly
reach the ipsec dst limit and are no longer usable.
Thanks!
up
with a negative dst_ops count while another winds up with a continually
increasing count, eventually reaching its gc_thresh limit, which causes
all new traffic on the net namespace to fail with -ENOBUFS.
Signed-off-by: Dan Streetman
Signed-off-by: Dan Streetman
---
Changes since v2:
remove
On Thu, Oct 29, 2015 at 7:57 AM, kbuild test robot wrote:
> Hi Dan,
>
> [auto build test WARNING on ipsec/master -- if it's inappropriate base,
> please suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/Dan-Stree
up
with a negative dst_ops count while another winds up with a continually
increasing count, eventually reaching its gc_thresh limit, which causes
all new traffic on the net namespace to fail with -ENOBUFS.
Signed-off-by: Dan Streetman
Signed-off-by: Dan Streetman
---
Changes since v1:
move dst c
On Wed, Oct 28, 2015 at 9:42 AM, Hannes Frederic Sowa
wrote:
> Hello,
>
> On Wed, Oct 28, 2015, at 14:32, Dan Streetman wrote:
>> On Tue, Oct 27, 2015 at 12:15 PM, wrote:
>> > From: Dan Streetman
>> >
>> > The ipv4 and ipv6 xfrms each create a
On Tue, Oct 27, 2015 at 12:15 PM, wrote:
> From: Dan Streetman
>
> The ipv4 and ipv6 xfrms each create a template dst_ops object, and
> perform dst_entries_init() on the template objects. Then each net
> namespace has its net.xfrm.xfrm[46]_dst_ops field set to the template
The driver currently waits 1us after issuing a RST, but the spec
requires it to wait 1ms. This adds a msleep(1) before polling the
reset bit.
Signed-off-by: Dan Streetman
Signed-off-by: Dan Streetman
---
changes since v1:
use msleep(1) instead of mdelay(1), per Peter Hurley
move msleep(1
, Jesse; Nelson, Shannon; Wyborny, Carolyn; Skidmore,
>> Donald C; Vick, Matthew; Ronciak, John; Williams, Mitch A; intel-wired-
>> l...@lists.osuosl.org; netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
>> Dan Streetman; Dan Streetman
>> Subject: [PATCH] ixgbe: Wai
, Jesse; Nelson, Shannon; Wyborny, Carolyn; Skidmore,
>> Donald C; Vick, Matthew; Ronciak, John; Williams, Mitch A; intel-wired-
>> l...@lists.osuosl.org; netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
>> Dan Streetman; Dan Streetman
>> Subject: [PATCH] ixgbe
From: Dan Streetman
The ipv4 and ipv6 xfrms each create a template dst_ops object, and
perform dst_entries_init() on the template objects. Then each net
namespace has its net.xfrm.xfrm[46]_dst_ops field set to the template
values. The problem with that is the dst_ops.pcpuc_entries field is
a
From: Dan Streetman
Spec section 8.2.4.1.1 notes that after setting the PCIe Master Disable
bit, it must be read to verify it was set before polling the Master Enable
status bit.
This adds the check to verify the Master Disable bit was set.
This also corrects the spec section number reference
From: Dan Streetman
The driver currently waits 1us after issuing a RST, but the spec
requires it to wait 1ms.
Signed-off-by: Dan Streetman
Signed-off-by: Dan Streetman
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a
On Wed, Sep 16, 2015 at 4:45 AM, Steffen Klassert
wrote:
> On Mon, Sep 14, 2015 at 11:14:59PM -0400, Dan Streetman wrote:
>> On Fri, Sep 11, 2015 at 5:48 AM, Steffen Klassert
>> wrote:
>> >
>> >> Possibly the
>> >> default value
On Fri, Sep 18, 2015 at 1:00 AM, Dan Streetman wrote:
> On Wed, Sep 16, 2015 at 4:45 AM, Steffen Klassert
> wrote:
>> On Mon, Sep 14, 2015 at 11:14:59PM -0400, Dan Streetman wrote:
>>> On Fri, Sep 11, 2015 at 5:48 AM, Steffen Klassert
>>> wrote:
>>> >
&
On Wed, Sep 16, 2015 at 4:45 AM, Steffen Klassert
wrote:
> On Mon, Sep 14, 2015 at 11:14:59PM -0400, Dan Streetman wrote:
>> On Fri, Sep 11, 2015 at 5:48 AM, Steffen Klassert
>> wrote:
>> >
>> >> Possibly the
>> >> default value
On Fri, Sep 11, 2015 at 5:48 AM, Steffen Klassert
wrote:
> Hi Dan.
>
> On Thu, Sep 10, 2015 at 05:01:26PM -0400, Dan Streetman wrote:
>> Hi Steffen,
>>
>> I've been working with Jay on a ipsec issue, which I believe he
>> discussed with you.
>
> Yes, w
Hi Steffen,
I've been working with Jay on a ipsec issue, which I believe he
discussed with you. In this case the xfrm4_garbage_collect is
returning error because the number of xfrm4 dst entries has exceeded
twice the gc_thresh, which causes new allocations of xfrm4 dst objects
to fail, thus makin
32 matches
Mail list logo
