* Re: [PATCH net-next 02/17] openvswitch: Shrink sw_flow_mask by 8 bytes (64-bit) or 4 bytes (32-bit).
From: Sergei Shtylyov @ 2014-01-07 21:36 UTC (permalink / raw)
To: Jesse Gross, David Miller, Ben Pfaff; +Cc: netdev, dev, Andy Zhou
In-Reply-To: <1389053776-62865-3-git-send-email-jesse@nicira.com>
On 07.01.2014 4:16, Jesse Gross wrote:
> From: Ben Pfaff <blp@nicira.com>
> We won't normally have a ton of flow masks but using a size_t to store
> values no bigger than sizeof(struct sw_flow_key) seems excessive.
> This reduces sw_flow_key_range and sw_flow_mask by 4 bytes on 32-bit
> systems. On 64-bit systems it shrinks sw_flow_key_range by 12 bytes but
> sw_flow_mask only by 8 bytes due to padding.
> Compile tested only.
> Signed-off-by: Ben Pfaff <blp@nicira.com>
> Acked-by: Andy Zhou <azhou@nicira.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> ---
> net/openvswitch/flow.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
> index 1510f51..176406d 100644
> --- a/net/openvswitch/flow.h
> +++ b/net/openvswitch/flow.h
> @@ -122,8 +122,8 @@ struct sw_flow_key {
> } __aligned(BITS_PER_LONG/8); /* Ensure that we can do comparisons as longs. */
>
> struct sw_flow_key_range {
> - size_t start;
> - size_t end;
> + unsigned short int start;
> + unsigned short int end;
*short int* seems somewhat ambiguous, no?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: stop vif thread spinning if frontend is unresponsive
From: David Miller @ 2014-01-07 21:29 UTC (permalink / raw)
To: paul.durrant; +Cc: netdev, xen-devel, wei.liu2, ian.campbell, david.vrabel
In-Reply-To: <1389111929-37231-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Tue, 7 Jan 2014 16:25:29 +0000
> @@ -477,6 +477,7 @@ static void xenvif_rx_action(struct xenvif *vif)
> unsigned long offset;
> struct skb_cb_overlay *sco;
> int need_to_notify = 0;
> + int ring_full = 0;
Please use bool, false, and true.
>
> - if (!npo.copy_prod)
> + if (!npo.copy_prod) {
> + if (ring_full)
> + vif->rx_queue_stopped = true;
> goto done;
> + }
> +
> + vif->rx_queue_stopped = false;
And then you can code this as:
vif->rx_queue_stopped = (!npo.copy_prod && ring_full);
if (!npo.copy_prod)
goto done;
^ permalink raw reply
* Re: [PATCH] mlx4_en: Select PTP_1588_CLOCK
From: David Miller @ 2014-01-07 21:24 UTC (permalink / raw)
To: shawn.bohrer
Cc: ogerlitz, amirv, richardcochran, netdev, tomk, hadarh, sbohrer
In-Reply-To: <1389120557-6773-1-git-send-email-shawn.bohrer@gmail.com>
From: Shawn Bohrer <shawn.bohrer@gmail.com>
Date: Tue, 7 Jan 2014 12:49:17 -0600
> From: Shawn Bohrer <sbohrer@rgmadvisors.com>
>
> Now that mlx4_en includes a PHC driver it must select PTP_1588_CLOCK.
>
> drivers/built-in.o: In function `mlx4_en_get_ts_info':
>>> en_ethtool.c:(.text+0x391a11): undefined reference to `ptp_clock_index'
> drivers/built-in.o: In function `mlx4_en_remove_timestamp':
>>> (.text+0x397913): undefined reference to `ptp_clock_unregister'
> drivers/built-in.o: In function `mlx4_en_init_timestamp':
>>> (.text+0x397b20): undefined reference to `ptp_clock_register'
>
> Fixes: ad7d4eaed995d ("mlx4_en: Add PTP hardware clock")
> Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net-gre-gro: Add GRE support to the GRO stack
From: David Miller @ 2014-01-07 21:22 UTC (permalink / raw)
To: hkchu; +Cc: edumazet, herbert, ogerlitz, netdev
In-Reply-To: <1389118999-16359-1-git-send-email-hkchu@google.com>
From: "H.K. Jerry Chu" <hkchu@google.com>
Date: Tue, 7 Jan 2014 10:23:19 -0800
> From: Jerry Chu <hkchu@google.com>
>
> This patch built on top of Commit 299603e8370a93dd5d8e8d800f0dff1ce2c53d36
> ("net-gro: Prepare GRO stack for the upcoming tunneling support") to add
> the support of the standard GRE (RFC1701/RFC2784/RFC2890) to the GRO
> stack. It also serves as an example for supporting other encapsulation
> protocols in the GRO stack in the future.
...
> Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
We really need to talk about what we want to happen with these GRO
offloads when GRE is not configured into the kernel.
Right now, the GRO offloads simply won't happen.
^ permalink raw reply
* Re: [PATCH v2] net: Do not enable tx-nocache-copy by default
From: David Miller @ 2014-01-07 21:20 UTC (permalink / raw)
To: bpoirier; +Cc: edumazet, netdev, linux-kernel, therbert
In-Reply-To: <1389107470-18213-1-git-send-email-bpoirier@suse.de>
From: Benjamin Poirier <bpoirier@suse.de>
Date: Tue, 7 Jan 2014 10:11:10 -0500
> There are many cases where this feature does not improve performance or even
> reduces it.
>
> For example, here are the results from tests that I've run using 3.12.6 on one
> Intel Xeon W3565 and one i7 920 connected by ixgbe adapters. The results are
> from the Xeon, but they're similar on the i7. All numbers report the
> mean±stddev over 10 runs of 10s.
>
> 1) latency tests similar to what is described in "c6e1a0d net: Allow no-cache
> copy from user on transmit"
> There is no statistically significant difference between tx-nocache-copy
> on/off.
> nic irqs spread out (one queue per cpu)
...
> CC: Tom Herbert <therbert@google.com>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: David Miller @ 2014-01-07 21:19 UTC (permalink / raw)
To: ogerlitz; +Cc: hkchu, edumazet, herbert, netdev, yanb, shlomop
In-Reply-To: <1389108594-665-2-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Tue, 7 Jan 2014 17:29:52 +0200
> +#define MAX_UDP_PORT (1 << 16)
> +extern const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT];
Bloating the kernel up by half a megabyte just for this feature is
beyond unacceptable.
^ permalink raw reply
* Re: [Patch net] cls_cgroup: fix memory leak in cls_cgroup_change()
From: Thomas Graf @ 2014-01-07 21:19 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <CAM_iQpU8rvceS7tAgv6DacHvaxJFBFDJSFhhBhWV-wqJ+A_xOA@mail.gmail.com>
On 01/06/14 at 03:23pm, Cong Wang wrote:
> On Fri, Jan 3, 2014 at 6:02 PM, David Miller <davem@davemloft.net> wrote:
> > From: Cong Wang <xiyou.wangcong@gmail.com>
> > Date: Fri, 3 Jan 2014 11:13:19 -0800
> >
> >> Fix it by moving allocation to ->init().
> >>
> >> Cc: Thomas Graf <tgraf@suug.ch>
> >> Cc: David S. Miller <davem@davemloft.net>
> >> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> >> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> >
> > I don't understand how the memory leak can happen, please explain
> > it in your commit message.
> >
>
> The leak happens when ->change() fails after the allocation
> inside cls_cgroup_change(), its caller only does cleanup
> when itself creates one. So, the callee should do cleanup
> on error path by itself. But I may miss something.
>
> Since it is not urgent at all, I will explain this in changelog
> and resend it for net-next.
I have no problem with the intent of the change but I want to
note that the behavior was introduced intentionally to be in
line with behaviour of other classifiers that use chaining.
It's not a leak, the reference is kept and freed when the
chain itself is deleted.
^ permalink raw reply
* Re: [PATCH net 1/1] tipc: correctly unlink packets from deferred packet queue
From: David Miller @ 2014-01-07 21:17 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion
In-Reply-To: <1389127896-7428-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 7 Jan 2014 15:51:36 -0500
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> When we pull a received packet from a link's 'deferred packets' queue
> for processing, its 'next' pointer is not cleared, and still refers to
> the next packet in that queue, if any. This is incorrect, but caused
> no harm before commit 40ba3cdf542a469aaa9083fa041656e59b109b90 ("tipc:
> message reassembly using fragment chain") was introduced. After that
> commit, it may sometimes lead to the following oops:
...
> This happens when the last fragment of a message has passed through the
> the receiving link's 'deferred packets' queue, and at least one other
> packet was added to that queue while it was there. After the fragment
> chain with the complete message has been successfully delivered to the
> receiving socket, it is released. Since 'next' pointer of the last
> fragment in the released chain now is non-NULL, we get the crash shown
> above.
>
> We fix this by clearing the 'next' pointer of all received packets,
> including those being pulled from the 'deferred' queue, before they
> undergo any further processing.
>
> Fixes: 40ba3cdf542a4 ("tipc: message reassembly using fragment chain")
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Reported-by: Ying Xue <ying.xue@windriver.com>
> Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 3/3] net: Add GRO support for vxlan traffic
From: Tom Herbert @ 2014-01-07 21:09 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric Dumazet, Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZ+_1z+Qq0U0XnEAMygXMXTivN7giZ5P-QH-L_dkz2_hFw@mail.gmail.com>
On Tue, Jan 7, 2014 at 12:12 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
> On Tue, Jan 7, 2014 at 10:02 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Tue, 2014-01-07 at 21:43 +0200, Or Gerlitz wrote:
>>> On Tue, Jan 7, 2014 at 8:08 PM, Tom Herbert <therbert@google.com> wrote:
>>
>>> > Why ^ instead of != ?
>>>
>>> The XOR approach is very popular in the GRO stack, e.g see the IPv4 chain
>>> of inet_gro_receive() && tcp_gro_receive(), I guess this might relates
>>> to more efficient assembly code for ^ vs. != and/or the fast/elegant
>>> transitive nature of that operator
>>
>> This trick is only needed/used when many compares are folded into a
>> single conditional :
>>
>> if (a->f1 != b->f1 || a->f2 != b->f2)
>>
>> ->
>>
>> if (((a->f1 ^ b->f1) | (a->f2 ^ b->f2)) != 0)
>>
>> Please do not use XOR for a single compare.
>
> OK, but just out of curiosity -- what's the reasoning? clarity or
> efficiency or both?
Both. Compiling a simple program and comparing alternatives: gcc
produced the identical code for the single conditional (^ vs !=)
using the cmp instruction. Testing the two conditional case like Eric
provided; the second method (using ^) resulted in 4 more instructions,
but only one branch as opposed to two in the first method (!=). Method
#1 has the advantage of short circuiting when the first condition is
true, so organizing the conditionals to maximize the probability of
short circuit could be beneficial.
>>
>>
>>
^ permalink raw reply
* Re: [patch net-next] ipv4: loopback device: ignore value changes after device is upped
From: David Miller @ 2014-01-07 20:55 UTC (permalink / raw)
To: jiri; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber, hannes
In-Reply-To: <1389106545-7940-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 7 Jan 2014 15:55:45 +0100
> When lo is brought up, new ifa is created. Then, devconf and neigh values
> bitfield should be set so later changes of default values would not
> affect lo values.
>
> Note that the same behaviour is in ipv6. Also note that this is likely
> not an issue in many distros (for example Fedora 19) because userspace
> sets address to lo manually before bringing it up.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Looks good, applied.
^ permalink raw reply
* Re: [PATCH net-next v5] IPv6: add the option to use anycast addresses as source addresses in echo reply
From: David Miller @ 2014-01-07 20:52 UTC (permalink / raw)
To: fx.lebail; +Cc: netdev, hannes, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <1389103047-3380-1-git-send-email-fx.lebail@yahoo.com>
From: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
Date: Tue, 7 Jan 2014 14:57:27 +0100
> This change allows to follow a recommandation of RFC4942.
>
> - Add "anycast_src_echo_reply" sysctl to control the use of anycast addresses
> as source addresses for ICMPv6 echo reply. This sysctl is false by default
> to preserve existing behavior.
> - Add inline check ipv6_anycast_destination().
> - Use them in icmpv6_echo_reply().
>
> Reference:
> RFC4942 - IPv6 Transition/Coexistence Security Considerations
> (http://tools.ietf.org/html/rfc4942#section-2.1.6)
>
> 2.1.6. Anycast Traffic Identification and Security
>
> [...]
> To avoid exposing knowledge about the internal structure of the
> network, it is recommended that anycast servers now take advantage of
> the ability to return responses with the anycast address as the
> source address if possible.
>
> Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
Looks good, applied, thanks.
^ permalink raw reply
* [PATCH net 1/1] tipc: correctly unlink packets from deferred packet queue
From: Jon Maloy @ 2014-01-07 20:51 UTC (permalink / raw)
To: davem; +Cc: Jon Maloy, netdev, tipc-discussion
From: Erik Hugne <erik.hugne@ericsson.com>
When we pull a received packet from a link's 'deferred packets' queue
for processing, its 'next' pointer is not cleared, and still refers to
the next packet in that queue, if any. This is incorrect, but caused
no harm before commit 40ba3cdf542a469aaa9083fa041656e59b109b90 ("tipc:
message reassembly using fragment chain") was introduced. After that
commit, it may sometimes lead to the following oops:
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: tipc
CPU: 4 PID: 0 Comm: swapper/4 Tainted: G W 3.13.0-rc2+ #6
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
task: ffff880017af4880 ti: ffff880017aee000 task.ti: ffff880017aee000
RIP: 0010:[<ffffffff81710694>] [<ffffffff81710694>] skb_try_coalesce+0x44/0x3d0
RSP: 0018:ffff880016603a78 EFLAGS: 00010212
RAX: 6b6b6b6bd6d6d6d6 RBX: ffff880013106ac0 RCX: ffff880016603ad0
RDX: ffff880016603ad7 RSI: ffff88001223ed00 RDI: ffff880013106ac0
RBP: ffff880016603ab8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88001223ed00
R13: ffff880016603ad0 R14: 000000000000058c R15: ffff880012297650
FS: 0000000000000000(0000) GS:ffff880016600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000805b000 CR3: 0000000011f5d000 CR4: 00000000000006e0
Stack:
ffff880016603a88 ffffffff810a38ed ffff880016603aa8 ffff88001223ed00
0000000000000001 ffff880012297648 ffff880016603b68 ffff880012297650
ffff880016603b08 ffffffffa0006c51 ffff880016603b08 00ffffffa00005fc
Call Trace:
<IRQ>
[<ffffffff810a38ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffffa0006c51>] tipc_link_recv_fragment+0xd1/0x1b0 [tipc]
[<ffffffffa0007214>] tipc_recv_msg+0x4e4/0x920 [tipc]
[<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
[<ffffffffa000177c>] tipc_l2_rcv_msg+0xcc/0x250 [tipc]
[<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
[<ffffffff8171e65b>] __netif_receive_skb_core+0x80b/0xd00
[<ffffffff8171df94>] ? __netif_receive_skb_core+0x144/0xd00
[<ffffffff8171eb76>] __netif_receive_skb+0x26/0x70
[<ffffffff8171ed6d>] netif_receive_skb+0x2d/0x200
[<ffffffff8171fe70>] napi_gro_receive+0xb0/0x130
[<ffffffff815647c2>] e1000_clean_rx_irq+0x2c2/0x530
[<ffffffff81565986>] e1000_clean+0x266/0x9c0
[<ffffffff81985f7b>] ? notifier_call_chain+0x2b/0x160
[<ffffffff8171f971>] net_rx_action+0x141/0x310
[<ffffffff81051c1b>] __do_softirq+0xeb/0x480
[<ffffffff819817bb>] ? _raw_spin_unlock+0x2b/0x40
[<ffffffff810b8c42>] ? handle_fasteoi_irq+0x72/0x100
[<ffffffff81052346>] irq_exit+0x96/0xc0
[<ffffffff8198cbc3>] do_IRQ+0x63/0xe0
[<ffffffff81981def>] common_interrupt+0x6f/0x6f
<EOI>
This happens when the last fragment of a message has passed through the
the receiving link's 'deferred packets' queue, and at least one other
packet was added to that queue while it was there. After the fragment
chain with the complete message has been successfully delivered to the
receiving socket, it is released. Since 'next' pointer of the last
fragment in the released chain now is non-NULL, we get the crash shown
above.
We fix this by clearing the 'next' pointer of all received packets,
including those being pulled from the 'deferred' queue, before they
undergo any further processing.
Fixes: 40ba3cdf542a4 ("tipc: message reassembly using fragment chain")
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reported-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/link.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 69cd9bf..13b9877 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1498,6 +1498,7 @@ void tipc_recv_msg(struct sk_buff *head, struct tipc_bearer *b_ptr)
int type;
head = head->next;
+ buf->next = NULL;
/* Ensure bearer is still enabled */
if (unlikely(!b_ptr->active))
--
1.7.9.5
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
^ permalink raw reply related
* Re: [PATCH net-next v5] IPv6: add the option to use anycast addresses as source addresses in echo reply
From: Hannes Frederic Sowa @ 2014-01-07 20:51 UTC (permalink / raw)
To: Francois-Xavier Le Bail
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy
In-Reply-To: <1389103047-3380-1-git-send-email-fx.lebail@yahoo.com>
On Tue, Jan 07, 2014 at 02:57:27PM +0100, Francois-Xavier Le Bail wrote:
> --- a/include/net/netns/ipv6.h
> +++ b/include/net/netns/ipv6.h
> @@ -73,6 +73,7 @@ struct netns_ipv6 {
> #endif
> atomic_t dev_addr_genid;
> atomic_t rt_genid;
> + int anycast_src_echo_reply;
> };
>
Sorry, I missed that on first review and you could also do that as a
follow-up:
Could you move anycast_src_echo_reply to netns_sysctl_ipv6?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 1/2] cxgb4: Fix namespace collision issue.
From: David Miller @ 2014-01-07 20:48 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, dm, leedom, nirranjan, kumaras, santosh
In-Reply-To: <1389094088-6261-2-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 7 Jan 2014 16:58:07 +0530
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
...
> -int t4_init_tp_params(struct adapter *adap)
There is no reason that an already exported function must be moved
to solve a namespace issue.
If you want to move this function for another reason, fine, but do
it in a seperate change with a clear description of that reason in
your commit message.
I'm not applying this series.
^ permalink raw reply
* [patch iproute2 v3 3/3] add support for IFA_F_NOPREFIXROUTE
From: Thomas Haller @ 2014-01-07 20:46 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Hannes Frederic Sowa, netdev, stephen, dcbw, Thomas Haller
In-Reply-To: <1388999830-1753-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Thomas Haller <thaller@redhat.com>
---
Hi,
this additional patch is based on the previous two patches v2,
so I reply to this email.
It's related to the discussion about adding a flag IFA_F_NOPREFIXROUTE
to suppress creation of prefix routes
(see thread "[patch iproute2 v2 0/2] add support for IFA_F_MANAGETEMPADDR",
from Thu, 2 Jan 2014 16:34:37 +0100).
include/linux/if_addr.h | 6 +++++-
ip/ipaddress.c | 11 ++++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index e1e95ce..cc375e4 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -18,6 +18,9 @@ struct ifaddrmsg {
* It makes no difference for normally configured broadcast interfaces,
* but for point-to-point IFA_ADDRESS is DESTINATION address,
* local address is supplied in IFA_LOCAL attribute.
+ *
+ * IFA_FLAGS is a u32 attribute that extends the u8 field ifa_flags.
+ * If present, the value from struct ifaddrmsg will be ignored.
*/
enum {
IFA_UNSPEC,
@@ -45,7 +48,8 @@ enum {
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE 0x40
#define IFA_F_PERMANENT 0x80
-#define IFA_F_MANAGETEMPADDR 0x0100
+#define IFA_F_MANAGETEMPADDR 0x100
+#define IFA_F_NOPREFIXROUTE 0x200
struct ifa_cacheinfo {
__u32 ifa_prefered;
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index b0d54fe..f794fa1 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -82,7 +82,7 @@ static void usage(void)
fprintf(stderr, " tentative | deprecated | dadfailed | temporary |\n");
fprintf(stderr, " CONFFLAG-LIST ]\n");
fprintf(stderr, "CONFFLAG-LIST := [ CONFFLAG-LIST ] CONFFLAG\n");
- fprintf(stderr, "CONFFLAG := [ home | nodad | mngtmpaddr ]\n");
+ fprintf(stderr, "CONFFLAG := [ home | nodad | mngtmpaddr | noprefixroute ]\n");
fprintf(stderr, "LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ]\n");
fprintf(stderr, "LFT := forever | SECONDS\n");
@@ -707,6 +707,10 @@ int print_addrinfo(const struct sockaddr_nl *who, struct nlmsghdr *n,
ifa_flags &= ~IFA_F_MANAGETEMPADDR;
fprintf(fp, "mngtmpaddr ");
}
+ if (ifa_flags & IFA_F_NOPREFIXROUTE) {
+ ifa_flags &= ~IFA_F_NOPREFIXROUTE;
+ fprintf(fp, "noprefixroute ");
+ }
if (!(ifa_flags & IFA_F_PERMANENT)) {
fprintf(fp, "dynamic ");
} else
@@ -1133,6 +1137,9 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
} else if (strcmp(*argv, "mngtmpaddr") == 0) {
filter.flags |= IFA_F_MANAGETEMPADDR;
filter.flagmask |= IFA_F_MANAGETEMPADDR;
+ } else if (strcmp(*argv, "noprefixroute") == 0) {
+ filter.flags |= IFA_F_NOPREFIXROUTE;
+ filter.flagmask |= IFA_F_NOPREFIXROUTE;
} else if (strcmp(*argv, "dadfailed") == 0) {
filter.flags |= IFA_F_DADFAILED;
filter.flagmask |= IFA_F_DADFAILED;
@@ -1354,6 +1361,8 @@ static int ipaddr_modify(int cmd, int flags, int argc, char **argv)
ifa_flags |= IFA_F_NODAD;
} else if (strcmp(*argv, "mngtmpaddr") == 0) {
ifa_flags |= IFA_F_MANAGETEMPADDR;
+ } else if (strcmp(*argv, "noprefixroute") == 0) {
+ ifa_flags |= IFA_F_NOPREFIXROUTE;
} else {
if (strcmp(*argv, "local") == 0) {
NEXT_ARG();
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH net] bnx2x: prevent WARN during driver unload
From: David Miller @ 2014-01-07 20:45 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, dmitry, ariele
In-Reply-To: <1389089261-25714-1-git-send-email-yuvalmin@broadcom.com>
From: Yuval Mintz <yuvalmin@broadcom.com>
Date: Tue, 7 Jan 2014 12:07:41 +0200
> + fp->state &= BNX2X_FP_STATE_DISABLED;
...
> + fp->state &= BNX2X_FP_STATE_DISABLED;
Surely you mean "&= ~BNX2X_FP_STATE_DISABLED" here?
^ permalink raw reply
* Re: [PATCH -next] net/mlx4_en: fix error return code in mlx4_en_get_qp()
From: David Miller @ 2014-01-07 20:43 UTC (permalink / raw)
To: weiyj.lk; +Cc: amirv, ogerlitz, yongjun_wei, netdev
In-Reply-To: <CAPgLHd9HUbNsD-rKi3CSVc6gG7TAn54mDJT2WcVu4K9kJ9PuYg@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 7 Jan 2014 16:56:07 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fix to return a negative error code from the error handling
> case instead of 0.
>
> Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling')
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: Or Gerlitz @ 2014-01-07 20:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
netdev@vger.kernel.org, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <1389126735.26646.65.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Jan 7, 2014 at 10:32 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-01-07 at 22:19 +0200, Or Gerlitz wrote:
>> On Tue, Jan 7, 2014 at 6:33 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Tue, 2014-01-07 at 17:29 +0200, Or Gerlitz wrote:
>> >>
>> >> +
>> >> +#define MAX_UDP_PORT (1 << 16)
>> >> +extern const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT];
>> >
>> > Thats 512 KB of memory.
>> > This will greatly impact forwarding performance of UDP packets with
>> > random ports, and will increase kernel memory size for embedded devices.
>>
>> Re forwarding, are you referring to the case where the forwarded
>> packets are encapsulated? packets which are not encapusalted will be
>> flushed in the gro receive handler (this went out by mistake in V2 but
>> exists in V1) if skb->encapsulation isn't set.
>>
>
> How do you know encapsulation must be tried for a given incoming
> packet ? NIC do not magically sets skb->encapsulation I think...
So here's the thing, per my understanding we want to GRO only received
**encapsulated** packets whose checksum status is != CHECKSUM_NONE
which means the NIC has some support for doing RX checksum of
encapsulated packets. Per the current convension, in that case the NIC
RX code has to set skb->encapsulation see 6a674e9c75b17 "net: Add
support for hardware-offloaded encapsulation" this convension is
implemented in the current drivers that have HW offloads for
encapsulated packets (bnx2x, i40e and mlx4)
>
> You access udp_offloads[XXX], with XXX being in 0..65535 range, right ?
>
>
>> As for encapsulated packets, when you say random ports, are you
>> referring to a router which has multiple udp encapsulating protocols
>> where each uses different udp port? for this case and also to reduce
>> the memory footprint, we can use lookup in a list as done for the L2
>> protocols gro handlers in the list_for_each loop of dev_gro_receive(),
>> makes sense?
>
> I am speaking of a normal router, running linux kernel, and having
> GRO/TSO enabled.
>
> If each incoming UDP packet has to access one extra cache line in a
> 512KB array, its likely to be an extra cache line miss, if UDP dest
> port is mostly random (compared to ports used by very recent UDP
> packets)
>
>
>
^ permalink raw reply
* Re: [net-next 01/15] i40e: Expose AQ debugfs hooks
From: David Miller @ 2014-01-07 20:34 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: anjali.singhai, netdev, gospo, sassmann, jesse.brandeburg
In-Reply-To: <1389087149-27962-2-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 7 Jan 2014 01:32:15 -0800
> @@ -1523,6 +1523,116 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
> } else {
> dev_info(&pf->pdev->dev, "clear_stats vsi [seid] or clear_stats pf\n");
> }
> + } else if (strncmp(cmd_buf, "send aq_cmd", 11) == 0) {
> + struct i40e_aq_desc *desc;
> + i40e_status ret;
> + desc = kzalloc(sizeof(struct i40e_aq_desc), GFP_KERNEL);
> + if (!desc)
> + goto command_write_done;
Please add an empty line between local variable declarations and code.
> + } else if (strncmp(cmd_buf, "send indirect aq_cmd", 20) == 0) {
> + struct i40e_aq_desc *desc;
> + i40e_status ret;
> + u16 buffer_len;
> + u8 *buff;
> + desc = kzalloc(sizeof(struct i40e_aq_desc), GFP_KERNEL);
> + if (!desc)
> + goto command_write_done;
Likewise.
^ permalink raw reply
* Re: [net-next 15/15] i40e: correctly setup ARQ descriptors
From: David Miller @ 2014-01-07 20:34 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: mitch.a.williams, netdev, gospo, sassmann, jesse.brandeburg
In-Reply-To: <1389087149-27962-16-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 7 Jan 2014 01:32:29 -0800
> + memset((void *)desc, 0, sizeof(struct i40e_aq_desc));
This is terrible.
First of all, no pointer need ever be cast when passed into memset()
because it accepts void * which is cleanly implicitly cast from any
pointer type. That's the whole reason memset accepts a void pointer,
so people don't need to ever cast the argument.
Secondly, using an explicit type to compute the size of the third
argument is error prone.
So please code this as the canonical:
memset(desc, 0, sizeof(*desc));
Thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: Eric Dumazet @ 2014-01-07 20:32 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
netdev@vger.kernel.org, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZ+q=uc4Svia+dFHrQfYyfJfsSVmqH1avJ99f4O0ES3QoQ@mail.gmail.com>
On Tue, 2014-01-07 at 22:19 +0200, Or Gerlitz wrote:
> On Tue, Jan 7, 2014 at 6:33 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Tue, 2014-01-07 at 17:29 +0200, Or Gerlitz wrote:
> >>
> >> +
> >> +#define MAX_UDP_PORT (1 << 16)
> >> +extern const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT];
> >
> > Thats 512 KB of memory.
> > This will greatly impact forwarding performance of UDP packets with
> > random ports, and will increase kernel memory size for embedded devices.
>
> Re forwarding, are you referring to the case where the forwarded
> packets are encapsulated? packets which are not encapusalted will be
> flushed in the gro receive handler (this went out by mistake in V2 but
> exists in V1) if skb->encapsulation isn't set.
>
How do you know encapsulation must be tried for a given incoming
packet ? NIC do not magically sets skb->encapsulation I think...
You access udp_offloads[XXX], with XXX being in 0..65535 range, right ?
> As for encapsulated packets, when you say random ports, are you
> referring to a router which has multiple udp encapsulating protocols
> where each uses different udp port? for this case and also to reduce
> the memory footprint, we can use lookup in a list as done for the L2
> protocols gro handlers in the list_for_each loop of dev_gro_receive(),
> makes sense?
I am speaking of a normal router, running linux kernel, and having
GRO/TSO enabled.
If each incoming UDP packet has to access one extra cache line in a
512KB array, its likely to be an extra cache line miss, if UDP dest
port is mostly random (compared to ports used by very recent UDP
packets)
^ permalink raw reply
* Re: Multicast routing stops functioning after 4G multicast packets recived.
From: Hannes Frederic Sowa @ 2014-01-07 20:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Bob Falken, Julian Anastasov, netdev
In-Reply-To: <1389126413.26646.60.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Jan 07, 2014 at 12:26:53PM -0800, Eric Dumazet wrote:
> On Tue, 2014-01-07 at 21:11 +0100, Hannes Frederic Sowa wrote:
>
> > It seems ip(6)mr_fib_lookup is not always called from rcu section
> > (ndo_start_xmit), so I had to restructure a bit. Could you retest this
> > patch as preparation for a submission to stable? Thanks!
> >
> > RCU conversion can be done later then.
> >
> > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> > index 421a249..9ae4ae7 100644
> > --- a/net/ipv4/ipmr.c
> > +++ b/net/ipv4/ipmr.c
>
> >
> > static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
> > {
> > + int err;
> > + struct ipmr_result res;
> > struct net *net = dev_net(dev);
> > - struct mr_table *mrt;
> > +
> > + struct fib_lookup_arg arg = {
> > + .result = &res,
> > + .flags = FIB_LOOKUP_NOREF,
> > + };
> > +
> > struct flowi4 fl4 = {
> > .flowi4_oif = dev->ifindex,
> > .flowi4_iif = skb->skb_iif,
> > .flowi4_mark = skb->mark,
> > };
> > - int err;
>
> Technically speaking, I don't think reg_vif_xmit() is enclosed
> in rcu_read_lock() section.
>
> >
> > - err = ipmr_fib_lookup(net, &fl4, &mrt);
> > + err = fib_rules_lookup(net->ipv4.mr_rules_ops,
> > + flowi4_to_flowi(&fl4), 0, &arg);
> > if (err < 0) {
> > kfree_skb(skb);
> > return err;
> > @@ -466,9 +476,12 @@ static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
> > read_lock(&mrt_lock);
> > dev->stats.tx_bytes += skb->len;
> > dev->stats.tx_packets++;
> > - ipmr_cache_report(mrt, skb, mrt->mroute_reg_vif_num, IGMPMSG_WHOLEPKT);
> > + ipmr_cache_report(res.mrt, skb, res.mrt->mroute_reg_vif_num,
> > + IGMPMSG_WHOLEPKT);
> > read_unlock(&mrt_lock);
> > kfree_skb(skb);
> > + if (arg.rule)
> > + fib_rule_put(arg.rule);
> > return NETDEV_TX_OK;
> > }
> >
>
> Hmm... Are you sure you meant to use FIB_LOOKUP_NOREF in
> reg_vif_xmit() ?
Nope, that's the reason for the second patch. Should have mentioned that.
Thanks for the review,
Hannes
^ permalink raw reply
* Re: Multicast routing stops functioning after 4G multicast packets recived.
From: Eric Dumazet @ 2014-01-07 20:26 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Bob Falken, Julian Anastasov, netdev
In-Reply-To: <20140107201147.GG30393@order.stressinduktion.org>
On Tue, 2014-01-07 at 21:11 +0100, Hannes Frederic Sowa wrote:
> It seems ip(6)mr_fib_lookup is not always called from rcu section
> (ndo_start_xmit), so I had to restructure a bit. Could you retest this
> patch as preparation for a submission to stable? Thanks!
>
> RCU conversion can be done later then.
>
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index 421a249..9ae4ae7 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
>
> static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> + int err;
> + struct ipmr_result res;
> struct net *net = dev_net(dev);
> - struct mr_table *mrt;
> +
> + struct fib_lookup_arg arg = {
> + .result = &res,
> + .flags = FIB_LOOKUP_NOREF,
> + };
> +
> struct flowi4 fl4 = {
> .flowi4_oif = dev->ifindex,
> .flowi4_iif = skb->skb_iif,
> .flowi4_mark = skb->mark,
> };
> - int err;
Technically speaking, I don't think reg_vif_xmit() is enclosed
in rcu_read_lock() section.
>
> - err = ipmr_fib_lookup(net, &fl4, &mrt);
> + err = fib_rules_lookup(net->ipv4.mr_rules_ops,
> + flowi4_to_flowi(&fl4), 0, &arg);
> if (err < 0) {
> kfree_skb(skb);
> return err;
> @@ -466,9 +476,12 @@ static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
> read_lock(&mrt_lock);
> dev->stats.tx_bytes += skb->len;
> dev->stats.tx_packets++;
> - ipmr_cache_report(mrt, skb, mrt->mroute_reg_vif_num, IGMPMSG_WHOLEPKT);
> + ipmr_cache_report(res.mrt, skb, res.mrt->mroute_reg_vif_num,
> + IGMPMSG_WHOLEPKT);
> read_unlock(&mrt_lock);
> kfree_skb(skb);
> + if (arg.rule)
> + fib_rule_put(arg.rule);
> return NETDEV_TX_OK;
> }
>
Hmm... Are you sure you meant to use FIB_LOOKUP_NOREF in
reg_vif_xmit() ?
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols
From: Or Gerlitz @ 2014-01-07 20:21 UTC (permalink / raw)
To: Tom Herbert
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CA+mtBx_UDWVP2KEB04d-kS4fB1DyYX4m-sC8YOZDy-Wty3cmtA@mail.gmail.com>
On Tue, Jan 7, 2014 at 8:44 PM, Tom Herbert <therbert@google.com> wrote:
> Or, thanks for posting the patches!
>
> We should also support the case where direct encapsulation is being
> done, that is there is no encapsulation header after UDP and the
> protocol of the encapsulated packet is inferred by the port number
> (e.g. GRE/UDP, TCP/UDP, SCTP/UDP, etc.). This is probably an
> additional field in net_offload struct for next protocol, a little
> more API, and pretty trivial handlers in UDP code.
The way I have set that follows your guideline under which the
encapsulating method is derived from the udp destination port in the
sense that the encapsulating protocol can do what they want in the
gro_receive/complete handlers entry they plant per that udp port,
isn't that generic enough?
>
>
> On Tue, Jan 7, 2014 at 7:29 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>> Add GRO handlers for protocols that do UDP encapsulation, with the intent of
>> being able to coalesce packets which encapsulate packets belonging to
>> the same TCP session.
>>
>> For GRO purposes, the destination UDP port takes the role of the ether type
>> field in the ethernet header or the next protocol in the IP header.
>>
>> The UDP GRO handler will only attempt to coalesce packets whose destination
>> port is registered to have gro handler.
>>
>> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>> ---
>> include/net/protocol.h | 6 ++++
>> net/ipv4/protocol.c | 21 ++++++++++++++
>> net/ipv4/udp_offload.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 96 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/protocol.h b/include/net/protocol.h
>> index fbf7676..d776c08 100644
>> --- a/include/net/protocol.h
>> +++ b/include/net/protocol.h
>> @@ -92,6 +92,10 @@ extern const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS];
>> extern const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS];
>> extern const struct net_offload __rcu *inet6_offloads[MAX_INET_PROTOS];
>>
>> +
>> +#define MAX_UDP_PORT (1 << 16)
>> +extern const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT];
>> +
>> #if IS_ENABLED(CONFIG_IPV6)
>> extern const struct inet6_protocol __rcu *inet6_protos[MAX_INET_PROTOS];
>> #endif
>> @@ -102,6 +106,8 @@ int inet_add_offload(const struct net_offload *prot, unsigned char num);
>> int inet_del_offload(const struct net_offload *prot, unsigned char num);
>> void inet_register_protosw(struct inet_protosw *p);
>> void inet_unregister_protosw(struct inet_protosw *p);
>> +int udp_add_offload(const struct net_offload *prot, __be16 port);
>> +int udp_del_offload(const struct net_offload *prot, __be16 port);
>>
>> #if IS_ENABLED(CONFIG_IPV6)
>> int inet6_add_protocol(const struct inet6_protocol *prot, unsigned char num);
>> diff --git a/net/ipv4/protocol.c b/net/ipv4/protocol.c
>> index 46d6a1c..426eae5 100644
>> --- a/net/ipv4/protocol.c
>> +++ b/net/ipv4/protocol.c
>> @@ -30,6 +30,7 @@
>>
>> const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS] __read_mostly;
>> const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS] __read_mostly;
>> +const struct net_offload __rcu *udp_offloads[MAX_UDP_PORT] __read_mostly;
>>
>> int inet_add_protocol(const struct net_protocol *prot, unsigned char protocol)
>> {
>> @@ -51,6 +52,13 @@ int inet_add_offload(const struct net_offload *prot, unsigned char protocol)
>> }
>> EXPORT_SYMBOL(inet_add_offload);
>>
>> +int udp_add_offload(const struct net_offload *prot, __be16 port)
>> +{
>> + return !cmpxchg((const struct net_offload **)&udp_offloads[port],
>> + NULL, prot) ? 0 : -1;
>> +}
>> +EXPORT_SYMBOL(udp_add_offload);
>> +
>> int inet_del_protocol(const struct net_protocol *prot, unsigned char protocol)
>> {
>> int ret;
>> @@ -76,3 +84,16 @@ int inet_del_offload(const struct net_offload *prot, unsigned char protocol)
>> return ret;
>> }
>> EXPORT_SYMBOL(inet_del_offload);
>> +
>> +int udp_del_offload(const struct net_offload *prot, __be16 port)
>> +{
>> + int ret;
>> +
>> + ret = (cmpxchg((const struct net_offload **)&udp_offloads[port],
>> + prot, NULL) == prot) ? 0 : -1;
>> +
>> + synchronize_net();
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(udp_del_offload);
>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>> index 79c62bd..0a8fdd6 100644
>> --- a/net/ipv4/udp_offload.c
>> +++ b/net/ipv4/udp_offload.c
>> @@ -89,10 +89,79 @@ out:
>> return segs;
>> }
>>
>> +
>> +static struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>> +{
>> + const struct net_offload *ops;
>> + struct sk_buff *p, **pp = NULL;
>> + struct udphdr *uh, *uh2;
>> + unsigned int hlen, off;
>> + int flush = 1;
>> +
>> + off = skb_gro_offset(skb);
>> + hlen = off + sizeof(*uh);
>> + uh = skb_gro_header_fast(skb, off);
>> + if (skb_gro_header_hard(skb, hlen)) {
>> + uh = skb_gro_header_slow(skb, hlen, off);
>> + if (unlikely(!uh))
>> + goto out;
>> + }
>> +
>> + rcu_read_lock();
>> + ops = rcu_dereference(udp_offloads[uh->dest]);
>> + if (!ops || !ops->callbacks.gro_receive)
>> + goto out_unlock;
>> +
>> + flush = 0;
>> +
>> + for (p = *head; p; p = p->next) {
>> + if (!NAPI_GRO_CB(p)->same_flow)
>> + continue;
>> +
>> + uh2 = (struct udphdr *)(p->data + off);
>> + if ((*(u32 *)&uh->source ^ *(u32 *)&uh2->source)) {
>> + NAPI_GRO_CB(p)->same_flow = 0;
>> + continue;
>> + }
>> + goto found;
>> + }
>> +
>> +found:
>> + skb_gro_pull(skb, sizeof(struct udphdr)); /* pull encapsulating udp header */
>> + pp = ops->callbacks.gro_receive(head, skb);
>> +
>> +out_unlock:
>> + rcu_read_unlock();
>> +out:
>> + NAPI_GRO_CB(skb)->flush |= flush;
>> +
>> + return pp;
>> +}
>> +
>> +static int udp_gro_complete(struct sk_buff *skb, int nhoff)
>> +{
>> + const struct net_offload *ops;
>> + __be16 newlen = htons(skb->len - nhoff);
>> + struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
>> + int err = -ENOSYS;
>> +
>> + uh->len = newlen;
>> +
>> + rcu_read_lock();
>> + ops = rcu_dereference(udp_offloads[uh->dest]);
>> + if (ops && ops->callbacks.gro_complete)
>> + err = ops->callbacks.gro_complete(skb, nhoff + sizeof(struct udphdr));
>> +
>> + rcu_read_unlock();
>> + return err;
>> +}
>> +
>> static const struct net_offload udpv4_offload = {
>> .callbacks = {
>> .gso_send_check = udp4_ufo_send_check,
>> .gso_segment = udp4_ufo_fragment,
>> + .gro_receive = udp_gro_receive,
>> + .gro_complete = udp_gro_complete,
>> },
>> };
>>
>> --
>> 1.7.1
>>
>> --
>> 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: Multicast routing stops functioning after 4G multicast packets recived.
From: Hannes Frederic Sowa @ 2014-01-07 20:20 UTC (permalink / raw)
To: Bob Falken, Julian Anastasov, netdev
In-Reply-To: <20140107201147.GG30393@order.stressinduktion.org>
On Tue, Jan 07, 2014 at 09:11:47PM +0100, Hannes Frederic Sowa wrote:
> On Tue, Jan 07, 2014 at 06:43:22PM +0100, Hannes Frederic Sowa wrote:
> > On Tue, Jan 07, 2014 at 06:01:44PM +0100, Bob Falken wrote:
> > > Hello,
> > >
> > > I patched, kernel 3.2.53 yesterday,
> > > 8774002632packets, and ~9.1TB later, the multicast routing seems to function properly. :)
> > >
> > > Kudos for fixing this.
> > >
> > > I will keep checking the next days.
> > >
> > > As for IPv6 MR, my current setup i.e: the Multicast source, does not support IPv6, so cannot do a check for that natively.
> > >
> > > Unless I can translate IPv4 multicast into IPv6 multicast easily, using some iptable prerouting rules(?).
> >
> > Thank you for testing!
> >
> > I'll review the RCU regions again and will prepare the patches (before
> > introduction of ebc0ffae5dfb44 ("fib: RCU conversion of fib_lookup()")
> > and after.
>
> It seems ip(6)mr_fib_lookup is not always called from rcu section
> (ndo_start_xmit), so I had to restructure a bit. Could you retest this
> patch as preparation for a submission to stable? Thanks!
>
> RCU conversion can be done later then.
Broken patch, sorry. Please try this one:
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 421a249..e5e9071 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -157,9 +157,12 @@ static struct mr_table *ipmr_get_table(struct net *net, u32 id)
static int ipmr_fib_lookup(struct net *net, struct flowi4 *flp4,
struct mr_table **mrt)
{
- struct ipmr_result res;
- struct fib_lookup_arg arg = { .result = &res, };
int err;
+ struct ipmr_result res;
+ struct fib_lookup_arg arg = {
+ .result = &res,
+ .flags = FIB_LOOKUP_NOREF,
+ };
err = fib_rules_lookup(net->ipv4.mr_rules_ops,
flowi4_to_flowi(flp4), 0, &arg);
@@ -448,16 +451,22 @@ failure:
static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
{
+ int err;
+ struct ipmr_result res;
struct net *net = dev_net(dev);
- struct mr_table *mrt;
+
+ struct fib_lookup_arg arg = {
+ .result = &res,
+ };
+
struct flowi4 fl4 = {
.flowi4_oif = dev->ifindex,
.flowi4_iif = skb->skb_iif,
.flowi4_mark = skb->mark,
};
- int err;
- err = ipmr_fib_lookup(net, &fl4, &mrt);
+ err = fib_rules_lookup(net->ipv4.mr_rules_ops,
+ flowi4_to_flowi(&fl4), 0, &arg);
if (err < 0) {
kfree_skb(skb);
return err;
@@ -466,9 +475,12 @@ static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
read_lock(&mrt_lock);
dev->stats.tx_bytes += skb->len;
dev->stats.tx_packets++;
- ipmr_cache_report(mrt, skb, mrt->mroute_reg_vif_num, IGMPMSG_WHOLEPKT);
+ ipmr_cache_report(res.mrt, skb, res.mrt->mroute_reg_vif_num,
+ IGMPMSG_WHOLEPKT);
read_unlock(&mrt_lock);
kfree_skb(skb);
+ if (arg.rule)
+ fib_rule_put(arg.rule);
return NETDEV_TX_OK;
}
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index f365310..45ec621 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -141,9 +141,12 @@ static struct mr6_table *ip6mr_get_table(struct net *net, u32 id)
static int ip6mr_fib_lookup(struct net *net, struct flowi6 *flp6,
struct mr6_table **mrt)
{
- struct ip6mr_result res;
- struct fib_lookup_arg arg = { .result = &res, };
int err;
+ struct ip6mr_result res;
+ struct fib_lookup_arg arg = {
+ .result = &res,
+ .flags = FIB_LOOKUP_NOREF,
+ };
err = fib_rules_lookup(net->ipv6.mr6_rules_ops,
flowi6_to_flowi(flp6), 0, &arg);
@@ -693,16 +696,20 @@ static const struct inet6_protocol pim6_protocol = {
static netdev_tx_t reg_vif_xmit(struct sk_buff *skb,
struct net_device *dev)
{
+ int err;
+ struct ip6mr_result res;
struct net *net = dev_net(dev);
- struct mr6_table *mrt;
struct flowi6 fl6 = {
.flowi6_oif = dev->ifindex,
.flowi6_iif = skb->skb_iif,
.flowi6_mark = skb->mark,
};
- int err;
+ struct fib_lookup_arg arg = {
+ .result = &res,
+ };
- err = ip6mr_fib_lookup(net, &fl6, &mrt);
+ err = fib_rules_lookup(net->ipv6.mr6_rules_ops,
+ flowi6_to_flowi(&fl6), 0, &arg);
if (err < 0) {
kfree_skb(skb);
return err;
@@ -711,9 +718,12 @@ static netdev_tx_t reg_vif_xmit(struct sk_buff *skb,
read_lock(&mrt_lock);
dev->stats.tx_bytes += skb->len;
dev->stats.tx_packets++;
- ip6mr_cache_report(mrt, skb, mrt->mroute_reg_vif_num, MRT6MSG_WHOLEPKT);
+ ip6mr_cache_report(res.mrt, skb, res.mrt->mroute_reg_vif_num,
+ MRT6MSG_WHOLEPKT);
read_unlock(&mrt_lock);
kfree_skb(skb);
+ if (arg.rule)
+ fib_rule_put(arg.rule);
return NETDEV_TX_OK;
}
^ 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