* network namespaces usage in routing appplications with VRF-like features
From: Jacob Avraham @ 2013-11-13 12:56 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
I'm trying to evaluate the use of network namespaces in some routing applications, which are currently based on the VFR patchset.
I was thinking about distributing several interfaces among a few namespaces, whereby each namespace has its own routing table(s), ala VRF.
The questions that I have are:
1. Can I open a listening socket that accepts traffic from all interfaces in all namespaces? That's the current behavior of my routing protocol daemons.
2. Does RTNETLINK API support adding routes to a particular namespace routing table?
Thanks,
Jacob
^ permalink raw reply
* Re: [Fwd: Re: [PATCH v2 2/2] x86: add prefetching to do_csum]
From: Ingo Molnar @ 2013-11-13 13:08 UTC (permalink / raw)
To: Neil Horman
Cc: David Laight, Joe Perches, netdev, Dave Jones, linux-kernel,
sebastien.dugue, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86, Eric Dumazet, Peter Zijlstra
In-Reply-To: <20131113123010.GB2993@hmsreliant.think-freely.org>
* Neil Horman <nhorman@tuxdriver.com> wrote:
> On Wed, Nov 13, 2013 at 10:09:51AM -0000, David Laight wrote:
> > > Sure, I modified the code so that we only prefetched 2 cache lines ahead, but
> > > only if the overall length of the input buffer is more than 2 cache lines.
> > > Below are the results (all counts are the average of 1000000 iterations of the
> > > csum operation, as previous tests were, I just omitted that column).
> >
> > Hmmm.... averaging over 100000 iterations means that all the code
> > is in the i-cache and the branch predictor will be correctly primed.
> >
> > For short checksum requests I'd guess that the relevant data
> > has just been written and is already in the cpu cache (unless
> > there has been a process and cpu switch).
> > So prefetch is likely to be unnecessary.
> >
> > If you assume that the checksum code isn't in the i-cache then
> > small requests are likely to be dominated by the code size.
>
> I'm not sure, whats the typical capacity for the branch predictors
> ability to remember code paths? I ask because the most likely use of
> do_csum will be in the receive path of the networking stack
> (specifically in the softirq handler). So if we run do_csum once, we're
> likely to run it many more times, as we clean out an adapters receive
> queue.
For such simple single-target branches it goes near or over a thousand for
recent Intel and AMD microarchitectures. Thousands for really recent CPUs.
Note that branch prediction caches are hierarchical and are typically
attached to cache hierarchies (where the uops are fetched from), so the
first level BTB is typically shared between SMT CPUs that share an icache
and L2 BTBs (which is larger and more associative) are shared by all cores
in a package.
So it's possible for some other task on another (sibling) CPU to keep
pressure on your BTB, but I'd say it's relatively rare, it's hard to do it
at a really high rate that blows away all the cache all the time. (PeterZ
has written some artificial pseudorandom branching monster just to be able
to generate cache misses and validate perf's branch stats - but even if
deliberately want to it's pretty hard to beat that cache.)
I'd definitely not worry about the prediction accuracy of repetitive loops
like csum routines, they'll be cached well.
Thanks,
Ingo
^ permalink raw reply
* RE: [Fwd: Re: [PATCH v2 2/2] x86: add prefetching to do_csum]
From: David Laight @ 2013-11-13 13:32 UTC (permalink / raw)
To: Ingo Molnar, Neil Horman
Cc: Joe Perches, netdev, Dave Jones, linux-kernel, sebastien.dugue,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Eric Dumazet,
Peter Zijlstra
In-Reply-To: <20131113130832.GB22140@gmail.com>
> > I'm not sure, whats the typical capacity for the branch predictors
> > ability to remember code paths?
...
>
> For such simple single-target branches it goes near or over a thousand for
> recent Intel and AMD microarchitectures. Thousands for really recent CPUs.
IIRC the x86 can also correctly predict simple sequences - like a branch
in a loop that is taken every other iteration, or only after a previous
branch is taken.
Much simpler cpus may use a much simpler strategy.
I think one I've used (a fpga soft-core cpu) just uses the low
bits of the instruction address to index a single bit table.
This means that branches alias each other.
In order to get the consistent cycle counts in order to minimise
the worst case code path we had to disable the dynamic prediction.
For the checksum code the loop branch isn't a problem.
Tests on entry to the function might get mispredicted.
So if you have conditional prefetch when the buffer is long
then time a short buffer after a 100 long ones you'll almost
certainly see the mispredition penalty.
FWIW I remember speeding up a copy (I think) loop on a strongarm by
adding an extra instruction to fetch a word from later in the buffer
into a register I never otherwise used.
(That was an unpaged system so I knew it couldn't fault.)
David
^ permalink raw reply
* Re: [Fwd: Re: [PATCH v2 2/2] x86: add prefetching to do_csum]
From: Ingo Molnar @ 2013-11-13 13:53 UTC (permalink / raw)
To: David Laight
Cc: Neil Horman, Joe Perches, netdev, Dave Jones, linux-kernel,
sebastien.dugue, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86, Eric Dumazet, Peter Zijlstra
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7412@saturn3.aculab.com>
* David Laight <David.Laight@ACULAB.COM> wrote:
> > > I'm not sure, whats the typical capacity for the branch predictors
> > > ability to remember code paths?
> ...
> >
> > For such simple single-target branches it goes near or over a thousand
> > for recent Intel and AMD microarchitectures. Thousands for really
> > recent CPUs.
>
> IIRC the x86 can also correctly predict simple sequences - like a branch
> in a loop that is taken every other iteration, or only after a previous
> branch is taken.
They tend to be rather capable but not very well documented :) With a
large out of order execution design and 20+ pipeline stages x86 branch
prediction accuracy is perhaps the most important design aspect to good
CPU performance.
> Much simpler cpus may use a much simpler strategy.
Yeah. The patches in this thread are about the x86 assembly implementation
of the csum routines, and for 'typical' x86 CPUs the branch prediction
units and caches are certainly sophisticated enough.
Also note that here, for real usecases, the csum routines are (or should
be) memory bandwidth limited, missing the data cache most of the time,
with a partially idling pipeline, while branch prediction accuracy matters
most when the pipeline is well fed and there are a lot of instructions in
flight.
Thanks,
Ingo
^ permalink raw reply
* how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-13 13:58 UTC (permalink / raw)
To: Linux Netdev List
Hello,
while my vlans, bridging and bonding stuff was working until 3.9 i never
thought about how it is right. So maybe i was always wrong.
I've this:
eth2
\
-- bond1 -- vmbr1
/
eth3
This works fine and as expected now i want to have a vlan using the
bonding and using a bridge.
I the past i had this:
eth2
\
-- bond1 -- vmbr1
/ \
eth3 \ vmbr1.3000
\ ---- tap114i1
This was working fine until 3.9.X since 3.10. Right now using 3.10 i
need to put eth2 and eth3 into promisc mode to get it working ;-( this
is bad!
I also tried this one without success:
eth2
\
-- bond1 -- vmbr1
/ \
eth3 ----- bond1.3000 --- vmbr1v3000
\ ---- tap114i1
Greets,
Stefan
^ permalink raw reply
* Re: [PATCH] tcp: tsq: restore minimal amount of queueing
From: Eric Dumazet @ 2013-11-13 14:06 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: David Miller, Sujith Manoharan, Cong Wang, netdev, Felix Fietkau
In-Reply-To: <1384267141.28458.24.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 2013-11-12 at 06:39 -0800, Eric Dumazet wrote:
> - limit = max(skb->truesize, sk->sk_pacing_rate >> 10);
> + limit = max(sysctl_tcp_limit_output_bytes,
> + sk->sk_pacing_rate >> 10);
>
I'll send a v2, a max_t(unsigned int, ..., ...) is needed here,
as reported by kbuild bot.
net/ipv4/tcp_output.c:1882:177: warning: comparison of distinct pointer
types lacks a cast [enabled by default]
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Veaceslav Falico @ 2013-11-13 14:12 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <52838590.5070806@profihost.ag>
On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG wrote:
>Hello,
>
>while my vlans, bridging and bonding stuff was working until 3.9 i never
>thought about how it is right. So maybe i was always wrong.
>
>I've this:
>
>eth2
> \
> -- bond1 -- vmbr1
> /
>eth3
>
>This works fine and as expected now i want to have a vlan using the
>bonding and using a bridge.
>
>I the past i had this:
>eth2
> \
> -- bond1 -- vmbr1
> / \
>eth3 \ vmbr1.3000
> \ ---- tap114i1
>
>This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>need to put eth2 and eth3 into promisc mode to get it working ;-( this
>is bad!
As a guess - do you use arp monitoring for bonding? Try using miimon -
there were some issues with it in 3.10, which were fixed by some huge
patchsets that will never hit 3.10 stable.
Also, the bonding configuration would be welcome.
>
>I also tried this one without success:
>eth2
> \
> -- bond1 -- vmbr1
> / \
>eth3 ----- bond1.3000 --- vmbr1v3000
> \ ---- tap114i1
>
>
>
>Greets,
>Stefan
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: shutdown(3) and bluetooth.
From: John W. Linville @ 2013-11-13 14:02 UTC (permalink / raw)
To: David Miller; +Cc: davej, netdev, linux-bluetooth, linux-wireless
In-Reply-To: <20131112.161350.946584501122269943.davem@davemloft.net>
On Tue, Nov 12, 2013 at 04:13:50PM -0500, David Miller wrote:
> From: Dave Jones <davej@redhat.com>
> Date: Tue, 12 Nov 2013 16:11:25 -0500
>
> > Is shutdown() allowed to block indefinitely ? The man page doesn't say either way,
> > and I've noticed that my fuzz tester occasionally hangs for days spinning in bt_sock_wait_state()
> >
> > Is there something I should be doing to guarantee that this operation
> > will either time out, or return instantly ?
> >
> > In this specific case, I doubt anything is on the "sender" end of the socket, so
> > it's going to be waiting forever for a state change that won't arrive.
>
> Adding bluetooth and wireless lists. Dave, please consult MAINTAINERS when
> asking questions like this, thanks!
I don't have an authoritative answer. I do, however, seem to recall
that trying to shutdown a SunOS box with a hung NFS mount would seem
to hang forever. I don't think that is a great metric for how we
should behave, of course...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH iproute2 v2] ss: avoid passing negative numbers to malloc
From: Eric Dumazet @ 2013-11-13 14:16 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: stephen, netdev
In-Reply-To: <20131113084642.GA23572@amd64.fatal.se>
On Wed, 2013-11-13 at 09:46 +0100, Andreas Henriksson wrote:
> Example:
>
> $ ss state established \( sport = :4060 or sport = :4061 or sport = :4062 or sport = :4063 or sport = :4064 or sport = :4065 or sport = :4066 or sport = :4067 \) > /dev/null
> Aborted
>
> In the example above ssfilter_bytecompile(...) will return (int)136.
> char l1 = 136; means -120 which will result in a negative number
> being passed to malloc at misc/ss.c:913.
>
> Simply declare l1 and l2 as integers to avoid the char overflow.
>
> This is one of the issues originally reported in http://bugs.debian.org/511720
>
> Fix the same problem in other code paths as well (thanks to Eric Dumazet).
>
> Reported-by: Andreas Schuldei <andreas@debian.org>
> Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH net-next 4/4] virtio-net: auto-tune mergeable rx buffer size for improved performance
From: Eric Dumazet @ 2013-11-13 14:19 UTC (permalink / raw)
To: Ronen Hod
Cc: Michael Dalton, Michael S. Tsirkin, netdev, Daniel Borkmann,
virtualization, Eric Dumazet, David S. Miller
In-Reply-To: <52833C9B.7070908@redhat.com>
On Wed, 2013-11-13 at 10:47 +0200, Ronen Hod wrote:
> I looked at how ewma works, and although it is computationally efficient,
> and it does what it is supposed to do, initially (at the first samples) it is strongly
> biased towards the value that was added at the first ewma_add.
> I suggest that you print the values of ewma_add() and ewma_read(). If you are
> happy with the results, then ignore my comments. If you are not, then I can
> provide a version that does better for the first samples.
> Unfortunately, it will be slightly less efficient.
Value is clamped by (GOOD_PACKET_LEN, PAGE_SIZE - hdr_len)
So initial value is conservative and not really used.
Thanks
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-13 14:20 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <20131113141244.GM19702@redhat.com>
Hi Falico,
Am 13.11.2013 15:12, schrieb Veaceslav Falico:
> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hello,
>>
>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>> thought about how it is right. So maybe i was always wrong.
>>
>> I've this:
>>
>> eth2
>> \
>> -- bond1 -- vmbr1
>> /
>> eth3
>>
>> This works fine and as expected now i want to have a vlan using the
>> bonding and using a bridge.
>>
>> I the past i had this:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>>
>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>> is bad!
>
> As a guess - do you use arp monitoring for bonding? Try using miimon -
> there were some issues with it in 3.10, which were fixed by some huge
> patchsets that will never hit 3.10 stable.
> Also, the bonding configuration would be welcome.
Debian Bonding konfiguration looks like this:
auto bond1
iface bond1 inet manual
slaves eth2 eth3
bond-mode 802.3ad
bond_miimon 100
bond_updelay 200
bond_downdelay 0
This should be miimon using lacp and not arp isn't it?
Anything more needed?
One thing i forgot the one with vmbr1.3000 does not work at all eben not
with promisc mode. The one below works fine if i set eth2 and eth3 into
promisc mode.
Stefan
>> I also tried this one without success:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>>
>>
>>
>> Greets,
>> Stefan
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH iproute2] htb: support 64bit rates
From: Eric Dumazet @ 2013-11-13 14:21 UTC (permalink / raw)
To: Yang Yingliang; +Cc: Stephen Hemminger, netdev
In-Reply-To: <52834248.3040103@huawei.com>
On Wed, 2013-11-13 at 17:11 +0800, Yang Yingliang wrote:
> > - if (!buffer) buffer = opt.rate.rate / get_hz() + mtu;
> > - if (!cbuffer) cbuffer = opt.ceil.rate / get_hz() + mtu;
> > + if (!buffer)
> > + buffer = rate64 / get_hz() + mtu;
> > + if (!cbuffer)
> > + cbuffer = ceil64 / get_hz() + mtu;
>
> Hi,
> It may overflow here if rate64 and mtu are big enough.
Not really.
get_hz() on current kernels is really huge : 1000000000
^ permalink raw reply
* Re: [PATCH 1/1] net: sctp: bug fixing when sctp path recovers
From: Vlad Yasevich @ 2013-11-13 14:22 UTC (permalink / raw)
To: Chang, nhorman, davem; +Cc: linux-sctp, netdev, linux-kernel, dreibh
In-Reply-To: <5282E9EC.3090307@gmail.com>
On 11/12/2013 09:54 PM, Chang wrote:
>
> On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
>> On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
>>> Look for the __two__ most recently used path/transport and set to
>>> active_path
>>> and retran_path respectively
>>>
>>> Signed-off-by: changxiangzhong@gmail.com
>>> ---
>>> net/sctp/associola.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
>>> index ab67efc..070011a 100644
>>> --- a/net/sctp/associola.c
>>> +++ b/net/sctp/associola.c
>>> @@ -913,11 +913,15 @@ void sctp_assoc_control_transport(struct
>>> sctp_association *asoc,
>>> if (!first || t->last_time_heard > first->last_time_heard) {
>>> second = first;
>>> first = t;
>>> + continue;
>>> }
>>> if (!second || t->last_time_heard > second->last_time_heard)
>>> second = t;
>>
>> You might as well remove this bit and then you don't need a continue.
> I don't think we could remove this bit. My understanding of these
> algorithms are to find the 1st recently used path and the 2nd, assigning
> to active_path and retran_path respectively. If we remove the
> looking-for-second block, how are we suppose to find the 2nd?
> I think we can remove the continue and use else-if in the
> 2nd-assignment-block.
Yes, you are right. An if...else block is what we need here.
-vlad
>>
>>> }
>>>
>>> + if (!second)
>>> + second = first;
>>> +
>>
>> This needs to move down 1 more block. Set the second transport after we
>> check to see if the primary is back up and we need to go back to using
>> it.
>>
>> -vlad
>>
> I agree with this change
>>> /* RFC 2960 6.4 Multi-Homed SCTP Endpoints
>>> *
>>> * By default, an endpoint should always transmit to the
>>>
>>
>
^ permalink raw reply
* Re: gso: Handle new frag_list of frags GRO packets
From: Herbert Xu @ 2013-11-13 14:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <1384310704.28458.79.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Nov 12, 2013 at 06:45:04PM -0800, Eric Dumazet wrote:
> On Wed, 2013-11-13 at 10:25 +0800, Herbert Xu wrote:
>
> > So a better test for the time being would be to test with TSO
> > disabled in both cases.
> >
>
> GRO on, TSO off, little difference between two cases :
>
> (Note some small things run in background, so these numbers are not
> ultra precise)
OK looks pretty sane.
> > In the mean time I'm cooking up a patch to generate TSO packets.
>
> That would be very nice !
It's failing on my machine but I'm not certain whether it's a bug
in my patch or a bug in my NIC's TSO code. So I'd appreciate it
if you can give this a spin on your mlx4.
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 557e1a5..1302515 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2786,6 +2786,8 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
__be16 proto;
bool csum;
int sg = !!(features & NETIF_F_SG);
+ int gso_type = 0;
+ int gso_size = 0;
int nfrags = skb_shinfo(skb)->nr_frags;
int err = -ENOMEM;
int i = 0;
@@ -2795,6 +2797,11 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (unlikely(!proto))
return ERR_PTR(-EINVAL);
+ if (net_gso_ok(gso_type, features)) {
+ gso_type = skb_shinfo(skb)->gso_type & ~SKB_GSO_DODGY;
+ gso_size = mss;
+ }
+
csum = !!can_checksum_protocol(features, proto);
__skb_push(skb, doffset);
headroom = skb_headroom(skb);
@@ -2807,7 +2814,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
int size;
len = skb->len - offset;
- if (len > mss)
+ if (!gso_size && len > mss)
len = mss;
hsize = skb_headlen(skb) - offset;
@@ -2819,6 +2826,26 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (!hsize && i >= nfrags && skb_headlen(fskb) &&
(skb_headlen(fskb) == len || sg)) {
BUG_ON(skb_headlen(fskb) > len);
+ SKB_FRAG_ASSERT(fskb);
+
+ nskb = skb_clone(fskb, GFP_ATOMIC);
+ if (unlikely(!nskb))
+ goto err;
+
+ if (gso_size) {
+ len = nskb->len;
+ pos += len;
+
+ skb_shinfo(nskb)->gso_segs = len / mss;
+
+ /*
+ * Original GRO packet boundaries must
+ * have been preserved.
+ */
+ BUG_ON(fskb->next && len % mss);
+
+ goto skip_trim;
+ }
i = 0;
nfrags = skb_shinfo(fskb)->nr_frags;
@@ -2837,17 +2864,14 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_frag++;
}
- nskb = skb_clone(fskb, GFP_ATOMIC);
- fskb = fskb->next;
-
- if (unlikely(!nskb))
- goto err;
-
if (unlikely(pskb_trim(nskb, len))) {
kfree_skb(nskb);
goto err;
}
+skip_trim:
+ fskb = fskb->next;
+
hsize = skb_end_offset(nskb);
if (skb_cow_head(nskb, doffset + headroom)) {
kfree_skb(nskb);
@@ -2880,6 +2904,9 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_headers_offset_update(nskb, skb_headroom(nskb) - headroom);
+ skb_shinfo(nskb)->gso_size = gso_size;
+ skb_shinfo(nskb)->gso_type = gso_type;
+
skb_copy_from_linear_data_offset(skb, -tnl_hlen,
nskb->data - tnl_hlen,
doffset + tnl_hlen);
@@ -2902,6 +2929,41 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_shinfo(nskb)->tx_flags = skb_shinfo(skb)->tx_flags & SKBTX_SHARED_FRAG;
+ /*
+ * virtio-net misery:
+ *
+ * Do a trial run for hardware GSO to get the proper length.
+ */
+ if (pos < offset + len && gso_size) {
+ int j;
+
+ len = hsize - (offset - pos);
+
+ for (j = i; j < nfrags; j++)
+ len += skb_frag_size(skb_frag + j);
+
+ if (fskb && !skb_headlen(fskb)) {
+ j = min_t(int,
+ skb_shinfo(fskb)->nr_frags,
+ MAX_SKB_FRAGS - nfrags + i);
+
+ while (--j >= 0)
+ len += skb_frag_size(
+ skb_shinfo(fskb)->frags + j);
+ }
+
+ if (len < mss && offset + len < skb->len)
+ goto too_many_frags;
+
+ skb_shinfo(nskb)->gso_segs = len / mss;
+ if (len % mss) {
+ if (offset + len >= skb->len)
+ skb_shinfo(nskb)->gso_segs++;
+ else
+ len -= len % mss;
+ }
+ }
+
while (pos < offset + len) {
if (i >= nfrags) {
BUG_ON(skb_headlen(fskb));
@@ -2917,6 +2979,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (unlikely(skb_shinfo(nskb)->nr_frags >=
MAX_SKB_FRAGS)) {
+too_many_frags:
net_warn_ratelimited(
"skb_segment: too many frags: %u %u\n",
pos, mss);
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH v2] tcp: tsq: restore minimal amount of queueing
From: Eric Dumazet @ 2013-11-13 14:32 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: David Miller, Sujith Manoharan, Cong Wang, netdev, Felix Fietkau
In-Reply-To: <1384267141.28458.24.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
After commit c9eeec26e32e ("tcp: TSQ can use a dynamic limit"), several
users reported throughput regressions, notably on mvneta and wifi
adapters.
802.11 AMPDU requires a fair amount of queueing to be effective.
This patch partially reverts the change done in tcp_write_xmit()
so that the minimal amount is sysctl_tcp_limit_output_bytes.
It also remove the use of this sysctl while building skb stored
in write queue, as TSO autosizing does the right thing anyway.
Users with well behaving NICS and correct qdisc (like sch_fq),
can then lower the default sysctl_tcp_limit_output_bytes value from
128KB to 8KB.
This new usage of sysctl_tcp_limit_output_bytes permits each driver
authors to check how their driver performs when/if the value is set
to a minimum of 4KB.
Normally, line rate for a single TCP flow should be possible,
but some drivers rely on timers to perform TX completion and
too long TX completion delays prevent reaching full throughput.
Fixes: c9eeec26e32e ("tcp: TSQ can use a dynamic limit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Sujith Manoharan <sujith@msujith.org>
Reported-by: Arnaud Ebalard <arno@natisbad.org>
Tested-by: Sujith Manoharan <sujith@msujith.org>
Cc: Felix Fietkau <nbd@openwrt.org>
---
v2: use a max_t() instead of max() to suppress a compiler warning
Documentation/networking/ip-sysctl.txt | 3 ---
net/ipv4/tcp.c | 6 ------
net/ipv4/tcp_output.c | 6 +++++-
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 8b8a057..3c12d9a 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -577,9 +577,6 @@ tcp_limit_output_bytes - INTEGER
typical pfifo_fast qdiscs.
tcp_limit_output_bytes limits the number of bytes on qdisc
or device to reduce artificial RTT/cwnd and reduce bufferbloat.
- Note: For GSO/TSO enabled flows, we try to have at least two
- packets in flight. Reducing tcp_limit_output_bytes might also
- reduce the size of individual GSO packet (64KB being the max)
Default: 131072
tcp_challenge_ack_limit - INTEGER
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 8e8529d..3dc0c6c 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -808,12 +808,6 @@ static unsigned int tcp_xmit_size_goal(struct sock *sk, u32 mss_now,
xmit_size_goal = min_t(u32, gso_size,
sk->sk_gso_max_size - 1 - hlen);
- /* TSQ : try to have at least two segments in flight
- * (one in NIC TX ring, another in Qdisc)
- */
- xmit_size_goal = min_t(u32, xmit_size_goal,
- sysctl_tcp_limit_output_bytes >> 1);
-
xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal);
/* We try hard to avoid divides here */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 6728546..c5231d9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1875,8 +1875,12 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
* - better RTT estimation and ACK scheduling
* - faster recovery
* - high rates
+ * Alas, some drivers / subsystems require a fair amount
+ * of queued bytes to ensure line rate.
+ * One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max(skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = max_t(unsigned int, sysctl_tcp_limit_output_bytes,
+ sk->sk_pacing_rate >> 10);
if (atomic_read(&sk->sk_wmem_alloc) > limit) {
set_bit(TSQ_THROTTLED, &tp->tsq_flags);
^ permalink raw reply related
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Veaceslav Falico @ 2013-11-13 14:34 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <52838AC8.8070005@profihost.ag>
On Wed, Nov 13, 2013 at 03:20:56PM +0100, Stefan Priebe - Profihost AG wrote:
>Hi Falico,
>Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hello,
>>>
>>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>>> thought about how it is right. So maybe i was always wrong.
>>>
>>> I've this:
>>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> /
>>> eth3
>>>
>>> This works fine and as expected now i want to have a vlan using the
>>> bonding and using a bridge.
>>>
>>> I the past i had this:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>>
>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>> is bad!
>>
>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>> there were some issues with it in 3.10, which were fixed by some huge
>> patchsets that will never hit 3.10 stable.
>> Also, the bonding configuration would be welcome.
>
>Debian Bonding konfiguration looks like this:
>auto bond1
>iface bond1 inet manual
> slaves eth2 eth3
> bond-mode 802.3ad
> bond_miimon 100
> bond_updelay 200
> bond_downdelay 0
>
>This should be miimon using lacp and not arp isn't it?
>Anything more needed?
Yeah, it's miimon, so nothing here...
I'll try to set up a reproducer in the nearest future, a bit burdened now.
Are you using 3.10.X stable? Which version exactly? And at what version did
it work - 3.9.?
Thank you!
>
>One thing i forgot the one with vmbr1.3000 does not work at all eben not
>with promisc mode. The one below works fine if i set eth2 and eth3 into
>promisc mode.
>
>Stefan
>
>>> I also tried this one without success:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>>
>>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-13 14:43 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <20131113143410.GN19702@redhat.com>
Am 13.11.2013 15:34, schrieb Veaceslav Falico:
> On Wed, Nov 13, 2013 at 03:20:56PM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hi Falico,
>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Hello,
>>>>
>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>> never
>>>> thought about how it is right. So maybe i was always wrong.
>>>>
>>>> I've this:
>>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> /
>>>> eth3
>>>>
>>>> This works fine and as expected now i want to have a vlan using the
>>>> bonding and using a bridge.
>>>>
>>>> I the past i had this:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>>
>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>> is bad!
>>>
>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>> there were some issues with it in 3.10, which were fixed by some huge
>>> patchsets that will never hit 3.10 stable.
>>> Also, the bonding configuration would be welcome.
>>
>> Debian Bonding konfiguration looks like this:
>> auto bond1
>> iface bond1 inet manual
>> slaves eth2 eth3
>> bond-mode 802.3ad
>> bond_miimon 100
>> bond_updelay 200
>> bond_downdelay 0
>>
>> This should be miimon using lacp and not arp isn't it?
>> Anything more needed?
>
> Yeah, it's miimon, so nothing here...
>
> I'll try to set up a reproducer in the nearest future, a bit burdened now.
>
> Are you using 3.10.X stable? Which version exactly? And at what version did
> it work - 3.9.?
I'm using 3.10.19 + this patchset from v3.12 (commit
b8bde1c4f94908ce8e3c0434fb369a00e9217497
Merge: 4b6c787 dfb5fa3
Author: David S. Miller <davem@davemloft.net>
Date: Fri Oct 18 16:03:03 2013 -0400
Merge branch 'bridge_pvid'
)
The problem is simply that the network cards and also the bonds do not
seem to know about the bridge on top so they just drop the vlan tagged
packages.
> Thank you!
>
>>
>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>> promisc mode.
>>
>> Stefan
>>
>>>> I also tried this one without success:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>>
>>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net RESEND] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-13 14:35 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131113100000.GH19702@redhat.com>
于 2013/11/13 18:00, Veaceslav Falico 写道:
> On Wed, Nov 13, 2013 at 10:19:02AM +0800, Ding Tianhong wrote:
>> I met a Bug when I add ip target with the wrong ip address:
>>
>> echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
>>
>> the wrong ip address will transfor to 245.245.245.244 and add
>> to the ip target success, it is uncorrect, so I add checks to avoid
>> adding wrong address.
>>
>> The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
>> the next check and will not add to ip target.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> drivers/net/bonding/bond_sysfs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/bonding/bond_sysfs.c
>> b/drivers/net/bonding/bond_sysfs.c
>> index ec9b646..e0c97fb 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -653,7 +653,7 @@ static ssize_t bonding_store_arp_targets(struct
>> device *d,
>> int ind, i, j, ret = -EINVAL;
>>
>> targets = bond->params.arp_targets;
>> - newtarget = in_aton(buf + 1);
>> + in4_pton(buf + 1, strlen(buf) - 1, (u8 *)&newtarget, -1, NULL);
>
> No need for strlen(buf)-1, if you specify -1 it will compute it by
> itself.
>
> Also, you might simplify the code a bit in the function. Otherwise -
> looks
> good, thank you.
>
> Untested patch:
>
> diff --git a/drivers/net/bonding/bond_sysfs.c
> b/drivers/net/bonding/bond_sysfs.c
> index c29b836..e3fff6e 100644
> --- a/drivers/net/bonding/bond_sysfs.c
> +++ b/drivers/net/bonding/bond_sysfs.c
> @@ -661,16 +661,16 @@ static ssize_t bonding_store_arp_targets(struct
> device *d,
> unsigned long *targets_rx;
> int ind, i, j, ret = -EINVAL;
>
> + if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL)) {
> + pr_err("%s: invalid ARP target specified, use +<addr> or -<addr>\n",
> + bond->dev->name);
> + goto out;
> + }
> +
> targets = bond->params.arp_targets;
> - newtarget = in_aton(buf + 1);
> +
> /* look for adds */
> if (buf[0] == '+') {
> - if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
> - pr_err("%s: invalid ARP target %pI4 specified for addition\n",
> - bond->dev->name, &newtarget);
> - goto out;
> - }
> -
> if (bond_get_targets_ip(targets, newtarget) != -1) { /* dup */
> pr_err("%s: ARP target %pI4 is already present\n",
> bond->dev->name, &newtarget);
> @@ -693,12 +693,6 @@ static ssize_t bonding_store_arp_targets(struct
> device *d,
> targets[ind] = newtarget;
> write_unlock_bh(&bond->lock);
> } else if (buf[0] == '-') {
> - if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
> - pr_err("%s: invalid ARP target %pI4 specified for removal\n",
> - bond->dev->name, &newtarget);
> - goto out;
> - }
> -
> ind = bond_get_targets_ip(targets, newtarget);
> if (ind == -1) {
> pr_err("%s: unable to remove nonexistent ARP target %pI4.\n",
> --
Although there is no substantial changes, but more simple more
beautiful, I'll take it,
resend it later, thanks for your opinion.
Regards
Ding
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: VLAN filtering/VLAN aware bridge problems
From: Vlad Yasevich @ 2013-11-13 14:49 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, vyasevic; +Cc: David Miller, Linux Netdev List
In-Reply-To: <52832A0B.9030605@profihost.ag>
On 11/13/2013 02:28 AM, Stefan Priebe - Profihost AG wrote:
> Am 13.11.2013 00:25, schrieb Vlad Yasevich:
>> On 11/12/2013 04:31 PM, Stefan Priebe wrote:
>>> sorry for the very late response.
>>>
>>> Am 10.09.2013 16:11, schrieb Vlad Yasevich:
>>>> On 08/30/2013 11:01 AM, Stefan Priebe - Profihost AG wrote:
>>>>> Yes
>>>>>
>>>>
>>>> Can you apply this patch and see if this fixes your problem.
>>>> http://patchwork.ozlabs.org/patch/273841/
>>>>
>>>> In my attempts to reproduce your problem I didn't configuring filtering
>>>> on the upper bridge, but that is what could have been causing
>>>> your problem. I'll attempt it and let you know.
>>>
>>> Even with the complete patchset which was merged upstream it doesn't
>>> work ;-(
>>>
>>> What's wrong there and / or how can i debug?
>>
>> Can you provide the filtering settings for both bridges you use?
>
> I don't filter at all right now it's compiled in but not enabled - but i
> have these problems since these patches were included.
>
> It only start to work if i set the eth0 and eth1 (slaves of the bond) to
> promisc mode. So the problem seems to be that the ethernet devices do
> not accept the VLAN tagged packages.
That doesn't make much sense. If the filtering is not enabled, then
this code isn't in use. It will not try to set any vlan filtering
so you should be running with essentially stock bridge.
Bridge sets promisc mode on all its ports, so your bond device should
be in promisc mode. Bonding code sets different set of slaves into
promisc mode depending on the mode you use. Which mode do you have
your bond configured in?
Does, dmesg tell you if devices have entered promisc mode?
-vlad
>
> Stefan
>
>> Thanks
>> -vlad
>>
>>>
>>> Stefan
>>>
>>>> -vlad
>>>>
>>>>
>>>>> Stefan
>>>>>
>>>>> This mail was sent with my iPhone.
>>>>>
>>>>> Am 30.08.2013 um 16:13 schrieb Vlad Yasevich <vyasevic@redhat.com>:
>>>>>
>>>>>> On 08/30/2013 03:24 AM, Stefan Priebe - Profihost AG wrote:
>>>>>>> Am 29.08.2013 22:45, schrieb Vlad Yasevich:
>>>>>>>> On 08/29/2013 08:50 AM, Stefan Priebe - Profihost AG wrote:
>>>>>>>
>>>>>>>>> The packets never reach the TAP device.
>>>>>>>>>
>>>>>>>>> Here is an output of ip a l (vlan 3021):
>>>>>>>>
>>>>>>>> Can you provide output of brctl show?
>>>>>>>
>>>>>>> Sure:
>>>>>>> # brctl show
>>>>>>> bridge name bridge id STP enabled interfaces
>>>>>>> vmbr0 8000.00259084dea8 no bond0
>>>>>>> tap320i0
>>>>>>> vmbr1 8000.00259084deaa no bond1
>>>>>>> vmbr1v3021 8000.00259084deaa no
>>>>>>> tap320i1
>>>>>>> vmbr1.3021
>>>>>>
>>>>>> so let me see if I can understand this configuration.
>>>>>>
>>>>>> vmbr1v3021 (bridge)
>>>>>> / \
>>>>>> tap320i1 vmbr1.3021 (vlan)
>>>>>> \
>>>>>> vmbr1 (bridge)
>>>>>> \
>>>>>> bond1
>>>>>> \
>>>>>> eth X
>>>>>>
>>>>>>
>>>>>> Is that right? Is this the setup that has the problem you are
>>>>>> describing?
>>>>>>
>>>>>> Thanks
>>>>>> -vlad
>>>>>>
>>>>>>>> On the off chance that you are actually trying to configure vlan
>>>>>>>> filtering, can you give this patch a try (net-2.6 tree):
>>>>>>>>
>>>>>>>> Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>> Date: Tue Aug 20 17:10:18 2013 +0900
>>>>>>>>
>>>>>>>> bridge: Use the correct bit length for bitmap functions in the
>>>>>>>> VLAN
>>>>>>>> code
>>>>>>>>
>>>>>>>> I don't think it made it to stable yet.
>>>>>>>
>>>>>>> I addd that patch and now the vlan stuff works at least on the host
>>>>>>> node. But my tap devices still don't work.
>>>>>>>
>>>>>>> I also tried to attach the tap device on top of a vlan attached to
>>>>>>> bond1
>>>>>>> but then gvrp does not work anymore. The kernel announces gvrp once
>>>>>>> and
>>>>>>> then does not answer the query packets from the switch.
>>>>>>>
>>>>>>> Stefan
>>>>>>
>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Subject: ref: Bridge Financial Services Ltd
From: Bowker Maxwell - DGM @ 2013-11-13 11:24 UTC (permalink / raw)
To: netdev
Hello,
Apply for all types of loans, credits or capital from us at 3% interest rate.
Contact us today, and discover how we can help.
Bowker Maxwell - DGM.
Bridge Financial Services Ltd.
Company No. 04625391
Bridge Financial Services Ltd.
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-13 15:05 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <52838AC8.8070005@profihost.ag>
On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
> Hi Falico,
> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hello,
>>>
>>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>>> thought about how it is right. So maybe i was always wrong.
>>>
>>> I've this:
>>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> /
>>> eth3
>>>
>>> This works fine and as expected now i want to have a vlan using the
>>> bonding and using a bridge.
>>>
>>> I the past i had this:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>>
>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>> is bad!
>>
>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>> there were some issues with it in 3.10, which were fixed by some huge
>> patchsets that will never hit 3.10 stable.
>> Also, the bonding configuration would be welcome.
>
> Debian Bonding konfiguration looks like this:
> auto bond1
> iface bond1 inet manual
> slaves eth2 eth3
> bond-mode 802.3ad
> bond_miimon 100
> bond_updelay 200
> bond_downdelay 0
>
> This should be miimon using lacp and not arp isn't it?
> Anything more needed?
>
Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
bond should place all of its ports into promiscuous mode. Do you see
the the kernel messages that say that?
-vlad
> One thing i forgot the one with vmbr1.3000 does not work at all eben not
> with promisc mode. The one below works fine if i set eth2 and eth3 into
> promisc mode.
>
> Stefan
>
>>> I also tried this one without success:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>>
>>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: gso: Handle new frag_list of frags GRO packets
From: Eric Dumazet @ 2013-11-13 15:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131113142615.GA1851@gondor.apana.org.au>
On Wed, 2013-11-13 at 22:26 +0800, Herbert Xu wrote:
> On Tue, Nov 12, 2013 at 06:45:04PM -0800, Eric Dumazet wrote:
> > On Wed, 2013-11-13 at 10:25 +0800, Herbert Xu wrote:
> >
> > > So a better test for the time being would be to test with TSO
> > > disabled in both cases.
> > >
> >
> > GRO on, TSO off, little difference between two cases :
> >
> > (Note some small things run in background, so these numbers are not
> > ultra precise)
>
> OK looks pretty sane.
>
> > > In the mean time I'm cooking up a patch to generate TSO packets.
> >
> > That would be very nice !
>
> It's failing on my machine but I'm not certain whether it's a bug
> in my patch or a bug in my NIC's TSO code. So I'd appreciate it
> if you can give this a spin on your mlx4.
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 557e1a5..1302515 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
Well, I wont try this patch, as it can not possibly work :(
The problem is not only skb_segment() but all its callers / users, as I
mentioned yesterday.
Specifically, you'll have to change inet_gso_segment(),
gre_gso_segment(), tcp_gso_segment(), ipv6_gso_segment(),
udp6_ufo_fragment() ...
Yes, we have to propagate correct IP id identifiers, and correct tcp
sequence numbers, tcp checksums.
^ permalink raw reply
* RE: [PATCH] rds: Error on offset mismatch if not loopback
From: Venkat Venkatsubra @ 2013-11-13 15:16 UTC (permalink / raw)
To: Josh Hunt, David Miller; +Cc: jjolly, LKML, netdev
In-Reply-To: <CAKA=qzYpd7Wo9XdU16TEhnbm5dPJjOZMhAY1jA7N+YFBWz5pzw@mail.gmail.com>
-----Original Message-----
From: Josh Hunt [mailto:joshhunt00@gmail.com]
Sent: Tuesday, November 12, 2013 10:25 PM
To: David Miller
Cc: jjolly@suse.com; LKML; Venkat Venkatsubra; netdev@vger.kernel.org
Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt <joshhunt00@gmail.com> wrote:
> On Sat, Sep 22, 2012 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
>>
>> From: John Jolly <jjolly@suse.com>
>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>
>> > Attempting an rds connection from the IP address of an IPoIB
>> > interface to itself causes a kernel panic due to a BUG_ON() being triggered.
>> > Making the test less strict allows rds-ping to work without
>> > crashing the machine.
>> >
>> > A local unprivileged user could use this flaw to crash the system.
>> >
>> > Signed-off-by: John Jolly <jjolly@suse.com>
>>
>> Besides the questions being asked of you by Venkat Venkatsubra, this
>> patch has another issue.
>>
>> It has been completely corrupted by your email client, it has turned
>> all TAB characters into spaces, making the patch useless.
>>
>> Please learn how to send a patch unmolested in the body of your
>> email. Test it by emailing the patch to yourself, and verifying that
>> you can in fact apply the patch you receive in that email.
>> Then, and only then, should you consider making a new submission of
>> this patch.
>>
>> Use Documentation/email-clients.txt for guidance.
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
> I think this issue was lost in the shuffle. It appears that redhat,
> ubuntu, and oracle are maintaining local patches to resolve this:
>
> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d63685
> 2be130fa15fa8be10d4704e8
> https://bugzilla.redhat.com/show_bug.cgi?id=822754
> http://ubuntu.5.x6.nabble.com/CVE-2012-2372-RDS-local-ping-DOS-td49853
> 88.html
>
> Given that Oracle has applied it I'll make the assumption that
> Venkat's question was answered at some point.
>
> David - I can resubmit the patch with the proper signed-off-by and
> formatting if you are willing to apply it unless John wants to try
> again. I think it's time this got upstream.
>
> --
> Josh
Ugh.. hopefully resending with all the html crap removed...
--
Josh
Hi Josh,
No, I still didn't get an answer for how "off" could be non-zero in case of rds-ping to hit BUG_ON(off % RDS_FRAG_SIZE).
Because, rds-ping uses zero byte messages to ping.
If you have a test case that reproduces the kernel panic I can try it out and see how that can happen.
The Oracle's internal code I checked doesn't have that patch applied.
Venkat
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-13 15:17 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <52839540.6020908@gmail.com>
Am 13.11.2013 16:05, schrieb Vlad Yasevich:
> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>> Hi Falico,
>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Hello,
>>>>
>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>> never
>>>> thought about how it is right. So maybe i was always wrong.
>>>>
>>>> I've this:
>>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> /
>>>> eth3
>>>>
>>>> This works fine and as expected now i want to have a vlan using the
>>>> bonding and using a bridge.
>>>>
>>>> I the past i had this:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>>
>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>> is bad!
>>>
>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>> there were some issues with it in 3.10, which were fixed by some huge
>>> patchsets that will never hit 3.10 stable.
>>> Also, the bonding configuration would be welcome.
>>
>> Debian Bonding konfiguration looks like this:
>> auto bond1
>> iface bond1 inet manual
>> slaves eth2 eth3
>> bond-mode 802.3ad
>> bond_miimon 100
>> bond_updelay 200
>> bond_downdelay 0
>>
>> This should be miimon using lacp and not arp isn't it?
>> Anything more needed?
>>
>
> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
> bond should place all of its ports into promiscuous mode. Do you see
> the the kernel messages that say that?
No it does not - i only see:
# dmesg -c|egrep "promiscuous|forward"
[ 5.445161] device bond0 entered promiscuous mode
[ 7.670701] device bond1 entered promiscuous mode
[ 7.845472] vmbr0: port 1(bond0) entered forwarding state
[ 7.845474] vmbr0: port 1(bond0) entered forwarding state
[ 8.269769] vmbr1: port 1(bond1) entered forwarding state
[ 8.269771] vmbr1: port 1(bond1) entered forwarding state
Now adding variant 1:
# dmesg -c|egrep "promiscuous|forward"
[ 85.919382] device tap113i0 entered promiscuous mode
[ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
[ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
[ 86.263292] device tap113i1 entered promiscuous mode
[ 86.314151] device vmbr1.3000 entered promiscuous mode
[ 86.314153] device vmbr1 entered promiscuous mode
[ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
[ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
[ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
Now it looks like this:
# ip a l|grep PROMISC
13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr0 state UNKNOWN qlen 500
14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr1v3000 state UNKNOWN qlen 500
Greets,
Stefan
Main question is - is this one correct:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
<= does not work at all
or this one?:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
<= works if i manually put eth2 and eth3 into promiscous mode.
> -vlad
>
>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>> promisc mode.
>>
>> Stefan
>>
>>>> I also tried this one without success:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>>
>>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* [PATCH net v2] ipv4: fix wildcard search with inet_confirm_addr()
From: Nicolas Dichtel @ 2013-11-13 15:23 UTC (permalink / raw)
To: ja; +Cc: davem, netdev, Nicolas Dichtel
In-Reply-To: <alpine.LFD.2.03.1311082258430.1811@ssi.bg>
Help of this function says: "in_dev: only on this interface, 0=any interface",
but since commit 39a6d0630012 ("[NETNS]: Process inet_confirm_addr in the
correct namespace."), the code supposes that it will never be NULL. This
function is never called with in_dev == NULL, but it's exported and may be used
by an external module.
Because this patch restore the ability to call inet_confirm_addr() with in_dev
== NULL, I partially revert the above commit, as suggested by Julian.
CC: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
This bug was spotted by code review.
v2: fix change in bond_confirm_addr()
partially revert 39a6d0630012 ("[NETNS]: Process inet_confirm_addr in the
correct namespace.")
fix API desc of inet_confirm_addr()
drivers/net/bonding/bonding.h | 4 ++--
include/linux/inetdevice.h | 3 ++-
net/ipv4/arp.c | 4 +++-
net/ipv4/devinet.c | 9 ++++-----
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 03cf3fd14490..0ad3f4bd99c0 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -414,8 +414,8 @@ static inline __be32 bond_confirm_addr(struct net_device *dev, __be32 dst, __be3
in_dev = __in_dev_get_rcu(dev);
if (in_dev)
- addr = inet_confirm_addr(in_dev, dst, local, RT_SCOPE_HOST);
-
+ addr = inet_confirm_addr(dev_net(dev), in_dev, dst, local,
+ RT_SCOPE_HOST);
rcu_read_unlock();
return addr;
}
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 79640e015a86..5870f7060917 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -164,7 +164,8 @@ extern int devinet_ioctl(struct net *net, unsigned int cmd, void __user *);
extern void devinet_init(void);
extern struct in_device *inetdev_by_index(struct net *, int);
extern __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope);
-extern __be32 inet_confirm_addr(struct in_device *in_dev, __be32 dst, __be32 local, int scope);
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev, __be32 dst,
+ __be32 local, int scope);
extern struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, __be32 prefix, __be32 mask);
static __inline__ int inet_ifa_match(__be32 addr, struct in_ifaddr *ifa)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 7808093cede6..46c7b4483bcf 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -379,6 +379,7 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
{
+ struct net *net = dev_net(in_dev->dev);
int scope;
switch (IN_DEV_ARP_IGNORE(in_dev)) {
@@ -397,6 +398,7 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
case 3: /* Do not reply for scope host addresses */
sip = 0;
scope = RT_SCOPE_LINK;
+ in_dev = NULL;
break;
case 4: /* Reserved */
case 5:
@@ -408,7 +410,7 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
default:
return 0;
}
- return !inet_confirm_addr(in_dev, sip, tip, scope);
+ return !inet_confirm_addr(net, in_dev, sip, tip, scope);
}
static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index a1b5bcbd04ae..19426e4b232c 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1236,22 +1236,21 @@ static __be32 confirm_addr_indev(struct in_device *in_dev, __be32 dst,
/*
* Confirm that local IP address exists using wildcards:
- * - in_dev: only on this interface, 0=any interface
+ * - net: netns to check, cannot be NULL
+ * - in_dev: only on this interface, NULL=any interface
* - dst: only in the same subnet as dst, 0=any dst
* - local: address, 0=autoselect the local address
* - scope: maximum allowed scope value for the local address
*/
-__be32 inet_confirm_addr(struct in_device *in_dev,
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev,
__be32 dst, __be32 local, int scope)
{
__be32 addr = 0;
struct net_device *dev;
- struct net *net;
- if (scope != RT_SCOPE_LINK)
+ if (in_dev != NULL)
return confirm_addr_indev(in_dev, dst, local, scope);
- net = dev_net(in_dev->dev);
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
in_dev = __in_dev_get_rcu(dev);
--
1.8.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox