* [patch net-next] sched: fix act file names in header comment
From: Jiri Pirko @ 2014-11-05 19:51 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs
Fixes: 4bba3925 ("[PKT_SCHED]: Prefix tc actions with act_")
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
net/sched/act_gact.c | 2 +-
net/sched/act_ipt.c | 2 +-
net/sched/act_mirred.c | 2 +-
net/sched/act_pedit.c | 2 +-
net/sched/act_police.c | 2 +-
net/sched/act_simple.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/sched/act_gact.c b/net/sched/act_gact.c
index d6bcbd9..7fffc22 100644
--- a/net/sched/act_gact.c
+++ b/net/sched/act_gact.c
@@ -1,5 +1,5 @@
/*
- * net/sched/gact.c Generic actions
+ * net/sched/act_gact.c Generic actions
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index 8a64a07..cbc8dd7 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -1,5 +1,5 @@
/*
- * net/sched/ipt.c iptables target interface
+ * net/sched/act_ipt.c iptables target interface
*
*TODO: Add other tables. For now we only support the ipv4 table targets
*
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index eb48306..5953517 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -1,5 +1,5 @@
/*
- * net/sched/mirred.c packet mirroring and redirect actions
+ * net/sched/act_mirred.c packet mirroring and redirect actions
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index 5f9bcb2..59649d5 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -1,5 +1,5 @@
/*
- * net/sched/pedit.c Generic packet editor
+ * net/sched/act_pedit.c Generic packet editor
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index 69791ca..9a1c42a 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -1,5 +1,5 @@
/*
- * net/sched/police.c Input police filter.
+ * net/sched/act_police.c Input police filter
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
index 992c231..6a8d948 100644
--- a/net/sched/act_simple.c
+++ b/net/sched/act_simple.c
@@ -1,5 +1,5 @@
/*
- * net/sched/simp.c Simple example of an action
+ * net/sched/act_simple.c Simple example of an action
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
--
1.9.3
^ permalink raw reply related
* Re: Kernel Oops in __inet_twsk_kill()
From: David Miller @ 2014-11-05 19:39 UTC (permalink / raw)
To: charley.chu; +Cc: cwang, borkmann, netdev
In-Reply-To: <FB8A4655DFD2B34DB16AE06DDDD6C0E231A71CE3@SJEXCHMB12.corp.ad.broadcom.com>
From: "Charley (Hao Chuan) Chu" <charley.chu@broadcom.com>
Date: Wed, 5 Nov 2014 19:16:09 +0000
> The problem has been fixed. It is introduced by a third party patch,
> which decreases the refcnt of timewait socket.
This is something that really drives me nuts, seriously?
Never report problems to us when you have such patches applied.
It is an even larger crime to not mention this at all from the
beginning, because we might start to investigate and waste our
precious time doing so.
^ permalink raw reply
* Re: [stable request <= 3.11] net/mlx4_en: Fix BlueFlame race
From: Vinson Lee @ 2014-11-05 19:38 UTC (permalink / raw)
To: stable
Cc: cwang, ben, Amir Vadai, Or Gerlitz, Jack Morgenstein,
Eugenia Emantayev, Matan Barak, netdev, David S. Miller
In-Reply-To: <20141103.150917.1015521239616746570.davem@davemloft.net>
On Mon, Nov 3, 2014 at 12:09 PM, David Miller <davem@davemloft.net> wrote:
> From: Cong Wang <cwang@twopensource.com>
> Date: Mon, 3 Nov 2014 09:22:18 -0800
>
>> On Sat, Nov 1, 2014 at 10:41 AM, David Miller <davem@davemloft.net> wrote:
>>>
>>> There is no documented way nor do I wish to state anything so strictly.
>>> I want maximum flexibility for such a time consuming task.
>>>
>>> I tend to go back 3 or 4 releases at most, and it really depends upon
>>> the difficulty of the backports and my own time constraints.
>>
>> You should really offload to developers, otherwise too much work for you. :)
>
> That's exactly what I am doing by having the -stable maintainers for older
> releases deal with the backports and other pains.
+ stable
Please backport upstream commit
2d4b646613d6b12175b017aca18113945af1faf3 "net/mlx4_en: Fix BlueFlame
race" to stable kernels. David is no longer supporting 3.10 and older.
Please refer to http://marc.info/?l=linux-netdev&m=141366689811844 for
previous comments in thread.
Cheers,
Vinson
^ permalink raw reply
* Re: [linux-nics] [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Jeff Kirsher @ 2014-11-05 19:36 UTC (permalink / raw)
To: Joe Stringer, Matthew Vick
Cc: linux.nics, shahed.shaikh, sathya.perla, Linux Netdev List, Vadai,
Linux Kernel, Tom Herbert, dept-gelinuxnicdev, Or Gerlitz, Amir
In-Reply-To: <CANr6G5xBehKGVozOAM=m8CXY7Q8_kPu-s5zgwho4=npv=bQsrg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]
On Wed, 2014-11-05 at 10:26 -0800, Joe Stringer wrote:
> On 5 November 2014 04:47, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> >
> > On Wed, 2014-11-05 at 14:44 +0200, Or Gerlitz wrote:
> > > On Wed, Nov 5, 2014 at 2:34 PM, Jeff Kirsher
> > > <jeffrey.t.kirsher@intel.com> wrote:
> > > > On Tue, 2014-11-04 at 13:56 -0800, Joe Stringer wrote:
> > > >> ndo_gso_check() was recently introduced to allow NICs to report the
> > > >> offloading support that they have on a per-skb basis. Add an
> > > >> implementation for this driver which checks for something that looks
> > > >> like VXLAN.
> > > >>
> > > >> Implementation shamelessly stolen from Tom Herbert:
> > > >> http://thread.gmane.org/gmane.linux.network/332428/focus=333111
> > > >>
> > > >> Signed-off-by: Joe Stringer <joestringer@nicira.com>
> > > >> ---
> > > >> Should this driver report support for GSO on packets with tunnel
> > > >> headers
> > > >> up to 64B like the i40e driver does?
> > > >> ---
> > > >> drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 12 ++++++++++++
> > > >> 1 file changed, 12 insertions(+)
> > > >
> > > > Thanks Joe, I will add your patch to my queue.
> > >
> > > Hi Jeff, please see my comment on patch 0/5, we're essentially
> > > replicating the same helper four different times (fm10k, mlx4, benet,
> > > qlgc) - I don't see the point in doing so. I asked Joe to come up with
> > > one generic helper and then to pick it up by the four drivers, makes
> > > sense?
> >
> > Yeah, I just saw your reply Or. Ok, I will await an update to Joe's
> > series, thanks!
>
> Thanks Or/Jeff.
>
> There is also the question in the commit message above, perhaps fm10k
> support is a bit different - wasn't sure who to ask regarding that.
Matthew Vick is the fm10k maintainer now and can answer any fm10k
questions you may have.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net v4] ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs
From: Daniel Borkmann @ 2014-11-05 19:27 UTC (permalink / raw)
To: davem
Cc: lw1a2.jing, netdev, Eric Dumazet, Hannes Frederic Sowa,
David L Stevens
It has been reported that generating an MLD listener report on
devices with large MTUs (e.g. 9000) and a high number of IPv6
addresses can trigger a skb_over_panic():
skbuff: skb_over_panic: text:ffffffff80612a5d len:3776 put:20
head:ffff88046d751000 data:ffff88046d751010 tail:0xed0 end:0xec0
dev:port1
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:100!
invalid opcode: 0000 [#1] SMP
Modules linked in: ixgbe(O)
CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 3.14.23+ #4
[...]
Call Trace:
<IRQ>
[<ffffffff80578226>] ? skb_put+0x3a/0x3b
[<ffffffff80612a5d>] ? add_grhead+0x45/0x8e
[<ffffffff80612e3a>] ? add_grec+0x394/0x3d4
[<ffffffff80613222>] ? mld_ifc_timer_expire+0x195/0x20d
[<ffffffff8061308d>] ? mld_dad_timer_expire+0x45/0x45
[<ffffffff80255b5d>] ? call_timer_fn.isra.29+0x12/0x68
[<ffffffff80255d16>] ? run_timer_softirq+0x163/0x182
[<ffffffff80250e6f>] ? __do_softirq+0xe0/0x21d
[<ffffffff8025112b>] ? irq_exit+0x4e/0xd3
[<ffffffff802214bb>] ? smp_apic_timer_interrupt+0x3b/0x46
[<ffffffff8063f10a>] ? apic_timer_interrupt+0x6a/0x70
mld_newpack() skb allocations are usually requested with dev->mtu
in size, since commit 72e09ad107e7 ("ipv6: avoid high order allocations")
we have changed the limit in order to be less likely to fail.
However, in MLD/IGMP code, we have some rather ugly AVAILABLE(skb)
macros, which determine if we may end up doing an skb_put() for
adding another record. To avoid possible fragmentation, we check
the skb's tailroom as skb->dev->mtu - skb->len, which is a wrong
assumption as the actual max allocation size can be much smaller.
The IGMP case doesn't have this issue as commit 57e1ab6eaddc
("igmp: refine skb allocations") stores the allocation size in
the cb[].
Set a reserved_tailroom to make it fit into the MTU and use
skb_availroom() helper instead. This also allows to get rid of
igmp_skb_size().
Reported-by: Wei Liu <lw1a2.jing@gmail.com>
Fixes: 72e09ad107e7 ("ipv6: avoid high order allocations")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: David L Stevens <david.stevens@oracle.com>
---
v3->v4:
- Reduced noise from previous one as discussed
v2->v3:
- Still had a discussion w/ Hannes and improved the code a bit as
suggested to make it more clear to read
v1->v2:
- Don't introduce skb_nofrag_tailroom(), but reuse skb_availroom()
as suggested by Eric
net/ipv4/igmp.c | 11 +++++------
net/ipv6/mcast.c | 9 +++++----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index fb70e3e..bb15d0e 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -318,9 +318,7 @@ igmp_scount(struct ip_mc_list *pmc, int type, int gdeleted, int sdeleted)
return scount;
}
-#define igmp_skb_size(skb) (*(unsigned int *)((skb)->cb))
-
-static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size)
+static struct sk_buff *igmpv3_newpack(struct net_device *dev, unsigned int mtu)
{
struct sk_buff *skb;
struct rtable *rt;
@@ -330,6 +328,7 @@ static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size)
struct flowi4 fl4;
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
+ unsigned int size = mtu;
while (1) {
skb = alloc_skb(size + hlen + tlen,
@@ -341,7 +340,6 @@ static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size)
return NULL;
}
skb->priority = TC_PRIO_CONTROL;
- igmp_skb_size(skb) = size;
rt = ip_route_output_ports(net, &fl4, NULL, IGMPV3_ALL_MCR, 0,
0, 0,
@@ -354,6 +352,8 @@ static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size)
skb_dst_set(skb, &rt->dst);
skb->dev = dev;
+ skb->reserved_tailroom = skb_end_offset(skb) -
+ min(mtu, skb_end_offset(skb));
skb_reserve(skb, hlen);
skb_reset_network_header(skb);
@@ -423,8 +423,7 @@ static struct sk_buff *add_grhead(struct sk_buff *skb, struct ip_mc_list *pmc,
return skb;
}
-#define AVAILABLE(skb) ((skb) ? ((skb)->dev ? igmp_skb_size(skb) - (skb)->len : \
- skb_tailroom(skb)) : 0)
+#define AVAILABLE(skb) ((skb) ? skb_availroom(skb) : 0)
static struct sk_buff *add_grec(struct sk_buff *skb, struct ip_mc_list *pmc,
int type, int gdeleted, int sdeleted)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 9648de2..ed2c4e4 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1550,7 +1550,7 @@ static void ip6_mc_hdr(struct sock *sk, struct sk_buff *skb,
hdr->daddr = *daddr;
}
-static struct sk_buff *mld_newpack(struct inet6_dev *idev, int size)
+static struct sk_buff *mld_newpack(struct inet6_dev *idev, unsigned int mtu)
{
struct net_device *dev = idev->dev;
struct net *net = dev_net(dev);
@@ -1561,13 +1561,13 @@ static struct sk_buff *mld_newpack(struct inet6_dev *idev, int size)
const struct in6_addr *saddr;
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
+ unsigned int size = mtu + hlen + tlen;
int err;
u8 ra[8] = { IPPROTO_ICMPV6, 0,
IPV6_TLV_ROUTERALERT, 2, 0, 0,
IPV6_TLV_PADN, 0 };
/* we assume size > sizeof(ra) here */
- size += hlen + tlen;
/* limit our allocations to order-0 page */
size = min_t(int, size, SKB_MAX_ORDER(0, 0));
skb = sock_alloc_send_skb(sk, size, 1, &err);
@@ -1576,6 +1576,8 @@ static struct sk_buff *mld_newpack(struct inet6_dev *idev, int size)
return NULL;
skb->priority = TC_PRIO_CONTROL;
+ skb->reserved_tailroom = skb_end_offset(skb) -
+ min(mtu, skb_end_offset(skb));
skb_reserve(skb, hlen);
if (__ipv6_get_lladdr(idev, &addr_buf, IFA_F_TENTATIVE)) {
@@ -1690,8 +1692,7 @@ static struct sk_buff *add_grhead(struct sk_buff *skb, struct ifmcaddr6 *pmc,
return skb;
}
-#define AVAILABLE(skb) ((skb) ? ((skb)->dev ? (skb)->dev->mtu - (skb)->len : \
- skb_tailroom(skb)) : 0)
+#define AVAILABLE(skb) ((skb) ? skb_availroom(skb) : 0)
static struct sk_buff *add_grec(struct sk_buff *skb, struct ifmcaddr6 *pmc,
int type, int gdeleted, int sdeleted, int crsend)
--
1.7.11.7
^ permalink raw reply related
* Re: Can ndo_select_queue save data in skb->cb?
From: John Fastabend @ 2014-11-05 19:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, James Yonan, netdev
In-Reply-To: <1415213589.13896.14.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/05/2014 10:53 AM, Eric Dumazet wrote:
> On Wed, 2014-11-05 at 10:38 -0800, Cong Wang wrote:
>> That is only because qdisc layer saves data for bond,
>> which means if you have more data to save, you have to put
>> more into qdisc CB, it is just ugly.
>
> Right, using skb->cb[] is ugly, dangerous, and all this.
>
> If you can, avoiding it is safer.
>
> Note that I pointed to the bonding case for a legal case,
> I had no time to do a full explanation, feel free to do so ;)
>
I would prefer to get rid of select_queue() versus expand
it. It mostly seems to be used for hacks around the stack
for FCoE/DCB/whatever. The wireless drivers and bonding/team
drivers are two examples where its not clear how to remove
it. See xen-netfront.c for an example where I'm not sure
why its needed at all.
James, why is your driver feeding itself data via cb? Maybe
we could solve the problem some other way.
Thanks,
John
>
>
> --
> 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
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* RE: Kernel Oops in __inet_twsk_kill()
From: Charley (Hao Chuan) Chu @ 2014-11-05 19:16 UTC (permalink / raw)
To: Cong Wang, Daniel Borkmann; +Cc: netdev
In-Reply-To: <CAHA+R7PAdVS=TBd8ZDAW3wdadjNEVjiyemrs54wNp8fdtCMvZQ@mail.gmail.com>
Thanks Daniel and Cong,
The problem has been fixed. It is introduced by a third party patch, which decreases the refcnt of timewait socket.
Charley
-----Original Message-----
From: Cong Wang [mailto:cwang@twopensource.com]
Sent: Wednesday, November 05, 2014 10:00 AM
To: Daniel Borkmann
Cc: Charley (Hao Chuan) Chu; netdev
Subject: Re: Kernel Oops in __inet_twsk_kill()
On Wed, Nov 5, 2014 at 8:00 AM, Daniel Borkmann <borkmann@iogearbox.net> wrote:
> [ moving to netdev ]
>
> -------- Original Message --------
> Subject: Kernel Oops in __inet_twsk_kill()
> Date: Tue, 4 Nov 2014 23:47:18 +0000
> From: Charley (Hao Chuan) Chu <charley.chu@broadcom.com>
> To: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
>
> We have situation on our system. It brings the network interface up and down
> every
> a few seconds. Eventually, it brings down the system - the kernel crashed
> due to BUG
> on in __inet_twsk_kill(). The debug message show following call flow.
>
> 1) time-wait socket is created by tcp_time_wait() when the socket gets into
> "TIME_WAIT" state.
> inet_twsk_alloc() - refcnt= 0
> inet_twsk_hashdance() - refcnt = 3
> inet_twsk_schedule() - refcnt = 4
> inet_twsk_put() - refcnt = 3
> 2) tcp_v4_timewait_ack() is called when sync is received
> inet_twsk_put() - refcnt= 2 <== where we thing the
> problem is
> occasionally, second sync is received, so the inet_twsk_put is called
> twice - refcnt = 1
> 3) twdr_do_twkill_work() is called when timed out
> call __inet_twsk_kill - BUG_ON!!! as refcnt=2 (supposed to be 3).
> call inet_twsk_put()
>
> In a normal case, the callflow only has step 1 and step 3. Our
> understanding is
> the time-wait socket has three references - ehash, bhash and timer death
> row. In
> step 2, none of them are touched. Can anyone here explain to us why the
> inet_twsk_put()
> is called in tcp_v4_timewait_ack()?
>
It has been there for a rather long time, but this doesn't mean it is
correct. Its caller calls inet_twsk_put() on error path, so smells wrong
to call it on non-error path. But I don't look into this.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: reclaim TX skbs only when released by the HW
From: Ian Campbell @ 2014-11-05 19:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ezequiel Garcia, Karl Beldan, David Miller, Karl Beldan, netdev,
Sebastian Hesselbarth
In-Reply-To: <1415202075.12206.0.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 2014-11-05 at 07:41 -0800, Eric Dumazet wrote:
> On Wed, 2014-11-05 at 11:46 -0300, Ezequiel Garcia wrote:
> > Hi Karl,
> >
> > On 11/05/2014 11:32 AM, Karl Beldan wrote:> From: Karl Beldan <karl.beldan@rivierawaves.com>
> > >
> > > ATM, txq_reclaim will dequeue and free an skb for each tx desc released
> > > by the hw that has TX_LAST_DESC set. However, in case of TSO, each
> > > hw desc embedding the last part of a segment has TX_LAST_DESC set,
> > > losing the one-to-one 'last skb frag'/'TX_LAST_DESC set' correspondance,
> > > which causes data corruption.
> > >
> > > Fix this by checking TX_ENABLE_INTERRUPT instead of TX_LAST_DESC, and
> > > warn when trying to dequeue from an empty txq (which can be symptomatic
> > > of releasing skbs prematurely).
> > >
> > > Fixes: 3ae8f4e0b98 ('net: mv643xx_eth: Implement software TSO')
> >
> > Although your change makes sense, this isn't fixing the issue for me,
> > neither did the previous one.
> >
> > Ian: Can you double check that you have corruption *without* the patch,
> > and that the patch fixes the issue?
Yes, doing md5sum on an NFS mount with 18 files in it I see 8-9
corrupted ones without any patch applied and none with Karl's previous
one from <20141104142020.GA6728@magnum.frso.rivierawaves.com> in place.
This was consistent over repeated invocations of md5sum (mounting and
unmounting around each one).
I've just confirmed this again to be sure.
The system is a QNAP TS-41x (armel, Feroceon 88FR131)
> Have you also applied my patch ?
I've only applied that one patch from Karl onto the 3.16.7 kernel which
is currently in Debian. Debian hasn't got any other mv643xx patches
applied.
I'm building now with Karl's latest patch from
<1415197979-1702-1-git-send-email-karl.beldan@gmail.com> instead.
Ian.
^ permalink raw reply
* [PATCH 3/3] mvebu: defconfig: Enable the mv88E6171 switch driver
From: Andrew Lunn @ 2014-11-05 19:02 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
In-Reply-To: <1415214121-29286-1-git-send-email-andrew@lunn.ch>
This switch is used by the 370-rd. Enable it and support for
fixed-link phy configuration.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/configs/mvebu_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index ed0a0d1be0f3..8548eee5cbeb 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -59,10 +59,12 @@ CONFIG_ATA=y
CONFIG_AHCI_MVEBU=y
CONFIG_SATA_MV=y
CONFIG_NETDEVICES=y
+CONFIG_NET_DSA_MV88E6171=y
CONFIG_MV643XX_ETH=y
CONFIG_MVNETA=y
CONFIG_MVPP2=y
CONFIG_MARVELL_PHY=y
+CONFIG_FIXED_PHY=y
CONFIG_MWIFIEX=y
CONFIG_MWIFIEX_SDIO=y
CONFIG_INPUT_EVDEV=y
--
2.1.3
^ permalink raw reply related
* [PATCH 1/3] dsa: mv88e6171: Add support for mv88e6172
From: Andrew Lunn @ 2014-11-05 19:01 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
In-Reply-To: <1415214121-29286-1-git-send-email-andrew@lunn.ch>
The mv88e6172 is very similar to the mv88e6171. So extend the
mv88e6171 driver to support it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/Kconfig | 6 +++---
drivers/net/dsa/mv88e6171.c | 5 ++++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 9234d808cbb3..69bed5b2f078 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -37,13 +37,13 @@ config NET_DSA_MV88E6123_61_65
ethernet switch chips.
config NET_DSA_MV88E6171
- tristate "Marvell 88E6171 ethernet switch chip support"
+ tristate "Marvell 88E6171/6172 ethernet switch chip support"
select NET_DSA
select NET_DSA_MV88E6XXX
select NET_DSA_TAG_EDSA
---help---
- This enables support for the Marvell 88E6171 ethernet switch
- chip.
+ This enables support for the Marvell 88E6171/6172 ethernet switch
+ chips.
config NET_DSA_BCM_SF2
tristate "Broadcom Starfighter 2 Ethernet switch support"
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 1020a7af67cf..d9919ce2b005 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -1,4 +1,4 @@
-/* net/dsa/mv88e6171.c - Marvell 88e6171 switch chip support
+/* net/dsa/mv88e6171.c - Marvell 88e6171/8826172 switch chip support
* Copyright (c) 2008-2009 Marvell Semiconductor
* Copyright (c) 2014 Claudio Leite <leitec@staticky.com>
*
@@ -29,6 +29,8 @@ static char *mv88e6171_probe(struct device *host_dev, int sw_addr)
if (ret >= 0) {
if ((ret & 0xfff0) == 0x1710)
return "Marvell 88E6171";
+ if ((ret & 0xfff0) == 0x1720)
+ return "Marvell 88E6172";
}
return NULL;
@@ -409,3 +411,4 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
};
MODULE_ALIAS("platform:mv88e6171");
+MODULE_ALIAS("platform:mv88e6172");
--
2.1.3
^ permalink raw reply related
* [PATCH 2/3] mvebu: 370 RD: Add support for the switch
From: Andrew Lunn @ 2014-11-05 19:02 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
In-Reply-To: <1415214121-29286-1-git-send-email-andrew@lunn.ch>
The 370 rd has a 7 port, mv88E6182 switch, connected to eth1. Add a
fixed-link subnode to the ethernet device tree node, to force
gigabit/full duplex. Add a dsa node, with describing the four used
ports. This requires adding an alias to the mdio node, so it can be
referenced as a phandle.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/armada-370-rd.dts | 49 ++++++++++++++++++++++++++++++++----
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index f57a8f841498..2bb671a778db 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -85,10 +85,6 @@
phy0: ethernet-phy@0 {
reg = <0>;
};
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
ethernet@70000 {
@@ -100,8 +96,11 @@
pinctrl-0 = <&ge1_rgmii_pins>;
pinctrl-names = "default";
status = "okay";
- phy = <&phy1>;
phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
mvsdio@d4000 {
@@ -173,4 +172,44 @@
};
};
};
+
+ dsa@0 {
+ compatible = "marvell,dsa";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ dsa,ethernet = <ð1>;
+ dsa,mii-bus = <&mdio>;
+
+ switch@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x10 0>; /* MDIO address 16, switch 0 in tree */
+
+ port@0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ };
+ };
+ };
};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 83286ec9702c..4d84ca981fe0 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -232,7 +232,7 @@
status = "disabled";
};
- mdio {
+ mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
--
2.1.3
^ permalink raw reply related
* [PATCH 0/3] Add support for switch on Armanda 370 RD
From: Andrew Lunn @ 2014-11-05 19:01 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
This patchset adds support for the switch chip found on the Marvell
370 RD board. The first patch extends the current mv88e6171 driver to
also support the mv88e6172. The second patch described the switch in
the device tree of the board, and the last patch enables require build
options in mvebu_v7_defconfig.
Davem should take patch #1
Jason Cooper should take patch #2 and #3.
Andrew Lunn (3):
dsa: mv88e6171: Add support for mv88e6172
mvebu: 370 RD: Add support for the switch
mvebu: defconfig: Enable the mv88E6171 switch driver
arch/arm/boot/dts/armada-370-rd.dts | 49 ++++++++++++++++++++++++++++++++----
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
arch/arm/configs/mvebu_v7_defconfig | 2 ++
drivers/net/dsa/Kconfig | 6 ++---
drivers/net/dsa/mv88e6171.c | 5 +++-
5 files changed, 54 insertions(+), 10 deletions(-)
--
2.1.3
^ permalink raw reply
* Payment
From: Finance Department @ 2014-11-05 18:49 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* Re: Can ndo_select_queue save data in skb->cb?
From: Eric Dumazet @ 2014-11-05 18:53 UTC (permalink / raw)
To: Cong Wang; +Cc: James Yonan, netdev
In-Reply-To: <CAHA+R7M2k8_9C8=kdAJT1nSFDhKfV2HwvTo0nX-tVDJQvXjy+w@mail.gmail.com>
On Wed, 2014-11-05 at 10:38 -0800, Cong Wang wrote:
> That is only because qdisc layer saves data for bond,
> which means if you have more data to save, you have to put
> more into qdisc CB, it is just ugly.
Right, using skb->cb[] is ugly, dangerous, and all this.
If you can, avoiding it is safer.
Note that I pointed to the bonding case for a legal case,
I had no time to do a full explanation, feel free to do so ;)
^ permalink raw reply
* Re: getting rid of ->splice_write?
From: Al Viro @ 2014-11-05 18:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Miklos Szeredi, linux-fsdevel, netdev
In-Reply-To: <20140922173053.GA13109@infradead.org>
On Mon, Sep 22, 2014 at 10:30:53AM -0700, Christoph Hellwig wrote:
> Currently only /dev/null, fusedev and the socket code have a
> splice_write implementation that isn't iter_file_splice_write, and
> it seems like these three could easily be switched over if they
> implemented a ->write_iter.
Not really. A minor nitpick is that you've missed port_fops_splice_write(),
but the real bitch isn't that and not even the sockets (see the fun with
iov_iter sendmsg/recvmsg work getting resurrected). It's that NULL
->splice_write() means default_file_splice_write. IOW, you'd need either
->write_iter() for _everything_ (with support of bvec-backed ones included,
since that's what iter_file_splice_write() will feed to ->write_iter()),
or you need to have do_splice_from() check if ->write_iter is NULL and
go for default_file_splice_write() instead of iter_file_splice_write().
The latter might be doable, but the former is really over the top - for
that we'd need to touch every driver instance of ->write() out there.
You want to do that, it's your funeral...
> Similarly it seems to be like we could kill ->splice_read by
> implementing an equivalent iteration over ->read_iter.
Hard to do. I agree that we want to, but it'll take quite a bit of work
on iov_iter primitives, I'm afraid. At the very least, we want a variant
of iov_iter that could steal pages. Don't forget that a large part of
the rationale behind splice_read was the ability to play zero-copy games.
I'm not sure if it will happen this cycle; there's more than enough fun
on the net/* side. _If_ that ends up done faster than I expect it to be,
->splice_read() is the obvious next target.
^ permalink raw reply
* [PATCH] net: dsa: slave: Fix autoneg for phys on switch MDIO bus
From: Andrew Lunn @ 2014-11-05 18:47 UTC (permalink / raw)
To: davem, f.fainelli; +Cc: netdev, Andrew Lunn
When the ports phys are connected to the switches internal MDIO bus,
we need to connect the phy to the slave netdev, otherwise
auto-negotiation etc, does not work.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
Hi Florian
Is this the right fix?
What i found is that ports on mv88E6171 we coming up as 10/half. If i
forced a renegotiation with ethtool -r lan0, the phy would then goto
1000/full.
The code for phys on internal switch MDIO buses never connect the phy
to the device, only phys listed in DT get connected via
of_phy_connect(). By connecting the phy, the state machine is active
and does an autoneg when the slave interface is opened.
net/dsa/slave.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 6d1817449c36..ab03e00ffe8f 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -489,11 +489,14 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
/* We could not connect to a designated PHY, so use the switch internal
* MDIO bus instead
*/
- if (!p->phy)
+ if (!p->phy) {
p->phy = ds->slave_mii_bus->phy_map[p->port];
- else
+ phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
+ p->phy_interface);
+ } else {
pr_info("attached PHY at address %d [%s]\n",
p->phy->addr, p->phy->drv->name);
+ }
}
int dsa_slave_suspend(struct net_device *slave_dev)
--
2.1.3
^ permalink raw reply related
* guten Tag,
From: Lubben Hendrik @ 2014-11-05 17:39 UTC (permalink / raw)
To: netdev
guten Tag,
Mein Name ist Lubben Hendrik und ich arbeite mit der Finanz- Haus hier in der Niederlande.
Ich fand Ihre Adresse durch meinen Ländern internationale Web Verzeichnis. Bei unserem letzten Treffen und Prüfung der Bankkonten
hier in den Niederlanden gefunden meine Abteilung ein ruhendes Konto mit einem enorme Summe von US $6.500.000,00
( sechs Millionen fünfhunderttausend USDollar ), die von verstorbenen Herrn Williams aus England abgelagert wurde .
Vor seinem Tod übernahm er die Summe von US $6.500.000,00 ( sechs Millionen fünfhunderttausend USDollar)an eine Bank hier in den Niederlanden. von unserem
Untersuchung hatte er keinen Empfänger oder nächsten Angehörigen , diese Mittel zu erreichen.
Aufgrund unserer finanziellen Hausordnung nur ein Ausländer kann als Stand-nächsten Verwandten oder nächsten Angehörigen . Der Antrag eines
Ausländers als nächsten Angehörigen ist die Basis auf der Tatsache, dass der Einleger ein Ausländer und jemand
in der war Niederlande kann nicht als die nächsten Angehörigen zu stehen.
Ich brauche Ihre Erlaubnis als nächster Verwandter oder nächsten Angehörigen unserer Verstorbenen
Kunden , so dass die Mittel freigegeben werden kann und Transfer zu Ihrem Konto , am Ende der Transaktion 40% wird für Sie sein und 60 % werden
für mich und meine Kollegen.
Wir brauchen ein ausländisches Konto . Ich immer noch auf die finanzielle Haus zu arbeiten , und das ist
der eigentliche Grund , dass ich eine zweite Partei oder Person brauchen ,zu stehen und zu arbeiten
mit mir und gelten für die Bank hier in den Niederlanden , wie die nächsten Angehörigen.
Ich habe in meinem Besitz alle notwendigen Unterlagen zu haben, diese Transaktion erfolgreich durchgeführt .
Weitere Informationen werden nach dem Eingang Ihrer Aufforderung zur Verfügung gestellt werden
Reaktion und ich möchte , dass Sie wissen , dass es kein Risiko. ich werde müssen uns zusammen zu arbeiten ,
wenn Sie interessiert sind , und ich versichere Ihnen, dass ich werden alle nützlichen Informationen und Dokumentation wie diese
Unternehmen zu schaffen braucht dringend Aufmerksamkeit,da es keine viel Zeit zu verlieren.
Bitte schreiben Sie mir direkt mit Ihrem Namen , Adresse , Telefon-und Faxnummer
auf diese E-Mail(lubbenhendrik1@aol.com)so kann ich erklären die Verfahren .
Grüße
Lubben Hendrik
^ permalink raw reply
* Re: Can ndo_select_queue save data in skb->cb?
From: Cong Wang @ 2014-11-05 18:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: James Yonan, netdev
In-Reply-To: <1415211391.13896.10.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Nov 5, 2014 at 10:16 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2014-11-05 at 10:57 -0700, James Yonan wrote:
>> Is it permissible for a net driver's ndo_select_queue method to save
>> data in skb->cb for later use in ndo_start_xmit?
>>
>> Also, is it necessary for users of skb->cb to zero out their private
>> data after use to prevent it from being misinterpreted by other layers?
>> I noticed some commits in the log (such as 462fb2) are zeroing out the
>> skb->cb area for this reason.
>
> Its ok to use skb->cb[] from ndo_select_queue()
>
> Look at bond_select_queue() for such a case.
>
> You do not need to cleanup skb->cb[] to zero before giving skb to the
> driver.
>
That is only because qdisc layer saves data for bond,
which means if you have more data to save, you have to put
more into qdisc CB, it is just ugly.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: reclaim TX skbs only when released by the HW
From: Karl Beldan @ 2014-11-05 18:31 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: David Miller, Ian Campbell, Karl Beldan, netdev, Eric Dumazet,
Sebastian Hesselbarth
In-Reply-To: <20141105150521.GA25354@magnum.frso.rivierawaves.com>
On Wed, Nov 05, 2014 at 04:05:21PM +0100, Karl Beldan wrote:
> On Wed, Nov 05, 2014 at 11:46:16AM -0300, Ezequiel Garcia wrote:
> > Hi Karl,
> >
> > On 11/05/2014 11:32 AM, Karl Beldan wrote:> From: Karl Beldan <karl.beldan@rivierawaves.com>
> > >
> > > ATM, txq_reclaim will dequeue and free an skb for each tx desc released
> > > by the hw that has TX_LAST_DESC set. However, in case of TSO, each
> > > hw desc embedding the last part of a segment has TX_LAST_DESC set,
> > > losing the one-to-one 'last skb frag'/'TX_LAST_DESC set' correspondance,
> > > which causes data corruption.
> > >
> > > Fix this by checking TX_ENABLE_INTERRUPT instead of TX_LAST_DESC, and
> > > warn when trying to dequeue from an empty txq (which can be symptomatic
> > > of releasing skbs prematurely).
> > >
> > > Fixes: 3ae8f4e0b98 ('net: mv643xx_eth: Implement software TSO')
> >
> > Although your change makes sense, this isn't fixing the issue for me,
> > neither did the previous one.
> >
> This change fixes a serious issue.
> On my side I can now trigger misc NFS and md5sums errors very easily,
> which I haven't detected so far with it applied.
> Are you running little endian ? Do you have the tso alignment fix
> a63ba13e (I don't expect it to be required but I don't know what SoC you
> are using) ? I suppose you are running with all 3 fixes applied.
>
Also, I haven't checked SMP issues and I only have one core, if you are
using SMP it might be worth looking into that, maybe try running on one
core only (I only have an MV78200).
Karl
^ permalink raw reply
* Re: Can ndo_select_queue save data in skb->cb?
From: Eric Dumazet @ 2014-11-05 18:16 UTC (permalink / raw)
To: James Yonan; +Cc: netdev
In-Reply-To: <545A64EC.309@openvpn.net>
On Wed, 2014-11-05 at 10:57 -0700, James Yonan wrote:
> Is it permissible for a net driver's ndo_select_queue method to save
> data in skb->cb for later use in ndo_start_xmit?
>
> Also, is it necessary for users of skb->cb to zero out their private
> data after use to prevent it from being misinterpreted by other layers?
> I noticed some commits in the log (such as 462fb2) are zeroing out the
> skb->cb area for this reason.
Its ok to use skb->cb[] from ndo_select_queue()
Look at bond_select_queue() for such a case.
You do not need to cleanup skb->cb[] to zero before giving skb to the
driver.
^ permalink raw reply
* M_CAN message RAM initialization AppNote - was: Re: [PATCH V3 3/3] can: m_can: workaround for transmit data less than 4 bytes
From: Oliver Hartkopp @ 2014-11-05 18:15 UTC (permalink / raw)
To: Marc Kleine-Budde, Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <545A3451.2090302@pengutronix.de>
Hi all,
just to close this application note relevant point ...
I got an answer from Florian Hartwich (Mr. CAN) from Bosch regarding the bit
error detection found by Dong Aisheng.
The relevant interrupts IR.BEU or IR.BEC monitor the message RAM:
Bit 21 BEU: Bit Error Uncorrected
Message RAM bit error detected, uncorrected. Controlled by input signal
m_can_aeim_berr[1] generated by an optional external parity / ECC logic
attached to the Message RAM. An uncorrected Message RAM bit error sets
CCCR.INIT to ‘1’. This is done to avoid transmission of corrupted data.
0= No bit error detected when reading from Message RAM
1= Bit error detected, uncorrected (e.g. parity logic)
Bit 20 BEC: Bit Error Corrected
Message RAM bit error detected and corrected. Controlled by input signal
m_can_aeim_berr[0] generated by an optional external parity / ECC logic
attached to the Message RAM.
0= No bit error detected when reading from Message RAM
1= Bit error detected and corrected (e.g. ECC)
---
The Message RAM is usually equipped with a parity or ECC functionality.
But RAM cells suffer a hardware reset and can therefore hold arbitrary content
at startup - including parity and/or ECC bits.
So when you write only the CAN ID and the first four bytes the last four bytes
remain untouched. Then the M_CAN starts to read in 32bit words from the start
of the Tx Message element. So it is very likely to trigger the message RAM
error when reading the uninitialized 32bit word from the last four bytes.
Finally it turns out that an initial writing (with any kind of data) to the
entire message RAM is mandatory to create valid parity/ECC checksums.
That's it.
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH] rtlwifi: Add more checks for get_btc_status callback
From: Larry Finger @ 2014-11-05 18:12 UTC (permalink / raw)
To: Mike Galbraith
Cc: Murilo Opsfelder Araujo, linux-kernel, linux-wireless, netdev,
Chaoming Li, John W. Linville, Thadeu Cascardo, troy_tan
In-Reply-To: <1415178975.5402.66.camel@marge.simpson.net>
On 11/05/2014 03:16 AM, Mike Galbraith wrote:
> On Wed, 2014-10-29 at 23:30 -0500, Larry Finger wrote:
>> On 10/29/2014 06:28 PM, Murilo Opsfelder Araujo wrote:
>>> This is a complement of commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
>>> "rtlwifi: Add check for get_btc_status callback".
>>>
>>> With this patch, next-20141029 at least does not panic with rtl8192se
>>> device.
>>>
>>
>> This patch is OK, but as noted it is not complete.
>>
>> I have patches to fix all the kernel panics for rtl8192se AND rtl8192ce. There
>> are missing parts, but I would prefer submitting mine, which would conflict with
>> this one. For that reason, NACK for this one, and please apply the set I am
>> submitting now.
>
> It's all in there now, but my RTL8191SEvB is still dead. Squabbling
> with it isn't going all that well either.
>
> As soon as 38506ece rtlwifi: rtl_pci: Start modification for new drivers
> is applied, explosions appear. Subsequently applying...
>
> 08054200 rtlwifi: Add check for get_btc_status callback
> c0386f15 rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing get_btc_status
> 50147969 rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
> 30c5ccc6 rtlwifi: rtl8192se: Add missing section to read descriptor setting
> 75a916e1 rtlwifi: rtl8192se: Fix firmware loading
>
> ...fixes that mess up, but leaves the interface dead in the same manner
> as if nothing has been reverted. So it _seems_ the bustage lurks in
> 38506ece somewhere. Too bad it's non-dinky, and written in wifi-ese :)
Yes, I am aware that rtl8192se is failing, and now that I am back from vacation,
I am working on the problem. If you want to use the driver with kernel 3.18,
clone the repo at http://github.com/lwfinger/rtlwifi_new.git and build and
install either the master or kernel_version branches. Both work.
I am in the process of trying to find what the crucial difference is between
that repo and the kernel version.
Larry
^ permalink raw reply
* [PATCH v2 iproute2 5/5] iproute2: Man pages for fou and gue
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
Man pages for Foo-over-UDP and Generic UDP Encapsulation receive
port configuration. gue man page links to fou one.
Signed-off-by: Tom Herbert <therbert@google.com>
---
man/man8/ip-fou.8 | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
man/man8/ip-gue.8 | 1 +
2 files changed, 77 insertions(+)
create mode 100644 man/man8/ip-fou.8
create mode 100644 man/man8/ip-gue.8
diff --git a/man/man8/ip-fou.8 b/man/man8/ip-fou.8
new file mode 100644
index 0000000..0fa22ee
--- /dev/null
+++ b/man/man8/ip-fou.8
@@ -0,0 +1,76 @@
+.TH IP\-FOU 8 "2 Nov 2014" "iproute2" "Linux"
+.SH "NAME"
+ip-fou \- Foo-over-UDP receive port configuration
+.P
+ip-gue \- Generic UDP Encapsulation receive port configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B fou
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+.BR "ip fou add"
+.B port
+.IR PORT
+.RB "{ "
+.B gue
+.RI "|"
+.B ipproto
+.IR PROTO
+.RB " }"
+.br
+.ti -8
+.BR "ip fou del"
+.B port
+.IR PORT
+.SH DESCRIPTION
+The
+.B ip fou
+commands are used to create and delete receive ports for Foo-over-UDP
+(FOU) as well as Generic UDP Encapsulation (GUE).
+.PP
+Foo-over-UDP allows encapsulating packets of an IP protocol directly
+over UDP. The receiver infers the protocol of a packet received on
+a FOU UDP port to be the protocol configured for the port.
+.PP
+Generic UDP Encapsulation (GUE) encapsulates packets of an IP protocol
+within UDP and an encapsulation header. The encapsulation header contains the
+IP protocol number for the encapsulated packet.
+.PP
+When creating a FOU or GUE receive port, the port number is specified in
+.I PORT
+argument. If FOU is used, the IP protocol number associated with the port is specified in
+.I PROTO
+argument.
+.PP
+A FOU or GUE receive port is deleted by specifying
+.I PORT
+in the delete command.
+.SH EXAMPLES
+.PP
+.SS Configure a FOU receive port for GRE bound to 7777
+.nf
+# ip fou add port 8888 ipproto 47
+.PP
+.SS Configure a FOU receive port for IPIP bound to 8888
+.nf
+# ip fou add port 8888 ipproto 4
+.PP
+.SS Configure a GUE receive port bound to 9999
+.nf
+# ip fou add port 9999 gue
+.PP
+.SS Delete the GUE receive port bound to 9999
+.nf
+# ip fou del port 9999
+.SH SEE ALSO
+.br
+.BR ip (8)
+.SH AUTHOR
+Tom Herbert <therbert@google.com>
diff --git a/man/man8/ip-gue.8 b/man/man8/ip-gue.8
new file mode 100644
index 0000000..4d2914c
--- /dev/null
+++ b/man/man8/ip-gue.8
@@ -0,0 +1 @@
+.so man8/ip-fou.8
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 iproute2 4/5] ip link: Add support for remote checksum offload
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
This patch adds support to remote checksum checksum offload
confinguration for IPIP, SIT, and GRE tunnels. This patch
adds a [no]encap-remcsum to ip link command which applicable
when configured tunnels that use GUE.
http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
Example:
ip link add name tun1 type gre remote 192.168.1.1 local 192.168.1.2 \
ttl 225 encap fou encap-sport auto encap-dport 7777 encap-csum \
encap-remcsum
This would create an GRE tunnel in GUE encapsulation where the source
port is automatically selected (based on hash of inner packet),
checksums in the encapsulating UDP header are enabled (needed.for
remote checksum offload), and remote checksum is configured to
be used on the tunnel (affects TX side).
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/if_tunnel.h | 1 +
ip/link_gre.c | 11 ++++++++++-
ip/link_iptnl.c | 11 ++++++++++-
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
index 8b04f32..102ce7a 100644
--- a/include/linux/if_tunnel.h
+++ b/include/linux/if_tunnel.h
@@ -69,6 +69,7 @@ enum tunnel_encap_types {
#define TUNNEL_ENCAP_FLAG_CSUM (1<<0)
#define TUNNEL_ENCAP_FLAG_CSUM6 (1<<1)
+#define TUNNEL_ENCAP_FLAG_REMCSUM (1<<2)
/* SIT-mode i_flags */
#define SIT_ISATAP 0x0001
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 47b64cb..1d78387 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -31,7 +31,7 @@ static void print_usage(FILE *f)
fprintf(f, " [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]\n");
fprintf(f, " [ noencap ] [ encap { fou | gue | none } ]\n");
fprintf(f, " [ encap-sport PORT ] [ encap-dport PORT ]\n");
- fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ]\n");
+ fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ] [ [no]encap-remcsum ]\n");
fprintf(f, "\n");
fprintf(f, "Where: NAME := STRING\n");
fprintf(f, " ADDR := { IP_ADDRESS | any }\n");
@@ -287,6 +287,10 @@ get_failed:
encapflags |= TUNNEL_ENCAP_FLAG_CSUM6;
} else if (strcmp(*argv, "noencap-udp6-csum") == 0) {
encapflags |= ~TUNNEL_ENCAP_FLAG_CSUM6;
+ } else if (strcmp(*argv, "encap-remcsum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_REMCSUM;
+ } else if (strcmp(*argv, "noencap-remcsum") == 0) {
+ encapflags |= ~TUNNEL_ENCAP_FLAG_REMCSUM;
} else
usage();
argc--; argv++;
@@ -445,6 +449,11 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
fputs("encap-csum6 ", f);
else
fputs("noencap-csum6 ", f);
+
+ if (flags & TUNNEL_ENCAP_FLAG_REMCSUM)
+ fputs("encap-remcsum ", f);
+ else
+ fputs("noencap-remcsum ", f);
}
}
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index 9487117..cab174f 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -31,7 +31,7 @@ static void print_usage(FILE *f, int sit)
fprintf(f, " [ 6rd-prefix ADDR ] [ 6rd-relay_prefix ADDR ] [ 6rd-reset ]\n");
fprintf(f, " [ noencap ] [ encap { fou | gue | none } ]\n");
fprintf(f, " [ encap-sport PORT ] [ encap-dport PORT ]\n");
- fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ]\n");
+ fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ] [ [no]encap-remcsum ]\n");
if (sit) {
fprintf(f, " [ mode { ip6ip | ipip | any } ]\n");
fprintf(f, " [ isatap ]\n");
@@ -256,6 +256,10 @@ get_failed:
encapflags |= TUNNEL_ENCAP_FLAG_CSUM6;
} else if (strcmp(*argv, "noencap-udp6-csum") == 0) {
encapflags &= ~TUNNEL_ENCAP_FLAG_CSUM6;
+ } else if (strcmp(*argv, "encap-remcsum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_REMCSUM;
+ } else if (strcmp(*argv, "noencap-remcsum") == 0) {
+ encapflags &= ~TUNNEL_ENCAP_FLAG_REMCSUM;
} else if (strcmp(*argv, "6rd-prefix") == 0) {
inet_prefix prefix;
NEXT_ARG();
@@ -438,6 +442,11 @@ static void iptunnel_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[
fputs("encap-csum6 ", f);
else
fputs("noencap-csum6 ", f);
+
+ if (flags & TUNNEL_ENCAP_FLAG_REMCSUM)
+ fputs("encap-remcsum ", f);
+ else
+ fputs("noencap-remcsum ", f);
}
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 iproute2 3/5] ip link gre: Add support to configure FOU and GUE
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
This patch adds support to configure foo-over-udp (FOU) and Generic
UDP Encapsulation for GRE tunnels. This configuration allows selection
of FOU or GUE for the tunnel, specification of the source and
destination ports for UDP tunnel, and enabling TX checksum. This
configuration only affects the transmit side of a tunnel.
Example:
ip link add name tun1 type gre remote 192.168.1.1 local 192.168.1.2 \
ttl 225 encap fou encap-sport auto encap-dport 7777 encap-csum
This would create an GRE tunnel in GUE encapsulation where the source
port is automatically selected (based on hash of inner packet) and
checksums in the encapsulating UDP header are enabled.
Signed-off-by: Tom Herbert <therbert@google.com>
---
ip/link_gre.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 83653d0..47b64cb 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -29,6 +29,9 @@ static void print_usage(FILE *f)
fprintf(f, " type { gre | gretap } [ remote ADDR ] [ local ADDR ]\n");
fprintf(f, " [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ]\n");
fprintf(f, " [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]\n");
+ fprintf(f, " [ noencap ] [ encap { fou | gue | none } ]\n");
+ fprintf(f, " [ encap-sport PORT ] [ encap-dport PORT ]\n");
+ fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ]\n");
fprintf(f, "\n");
fprintf(f, "Where: NAME := STRING\n");
fprintf(f, " ADDR := { IP_ADDRESS | any }\n");
@@ -67,6 +70,10 @@ static int gre_parse_opt(struct link_util *lu, int argc, char **argv,
__u8 ttl = 0;
__u8 tos = 0;
int len;
+ __u16 encaptype = 0;
+ __u16 encapflags = 0;
+ __u16 encapsport = 0;
+ __u16 encapdport = 0;
if (!(n->nlmsg_flags & NLM_F_CREATE)) {
memset(&req, 0, sizeof(req));
@@ -132,6 +139,15 @@ get_failed:
if (greinfo[IFLA_GRE_LINK])
link = rta_getattr_u8(greinfo[IFLA_GRE_LINK]);
+
+ if (greinfo[IFLA_GRE_ENCAP_TYPE])
+ encaptype = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_TYPE]);
+ if (greinfo[IFLA_GRE_ENCAP_FLAGS])
+ encapflags = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_FLAGS]);
+ if (greinfo[IFLA_GRE_ENCAP_SPORT])
+ encapsport = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_SPORT]);
+ if (greinfo[IFLA_GRE_ENCAP_DPORT])
+ encapdport = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_DPORT]);
}
while (argc > 0) {
@@ -241,6 +257,36 @@ get_failed:
tos = uval;
} else
tos = 1;
+ } else if (strcmp(*argv, "noencap") == 0) {
+ encaptype = TUNNEL_ENCAP_NONE;
+ } else if (strcmp(*argv, "encap") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "fou") == 0)
+ encaptype = TUNNEL_ENCAP_FOU;
+ else if (strcmp(*argv, "gue") == 0)
+ encaptype = TUNNEL_ENCAP_GUE;
+ else if (strcmp(*argv, "none") == 0)
+ encaptype = TUNNEL_ENCAP_NONE;
+ else
+ invarg("Invalid encap type.", *argv);
+ } else if (strcmp(*argv, "encap-sport") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "auto") == 0)
+ encapsport = 0;
+ else if (get_u16(&encapsport, *argv, 0))
+ invarg("Invalid source port.", *argv);
+ } else if (strcmp(*argv, "encap-dport") == 0) {
+ NEXT_ARG();
+ if (get_u16(&encapdport, *argv, 0))
+ invarg("Invalid destination port.", *argv);
+ } else if (strcmp(*argv, "encap-csum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_CSUM;
+ } else if (strcmp(*argv, "noencap-csum") == 0) {
+ encapflags &= ~TUNNEL_ENCAP_FLAG_CSUM;
+ } else if (strcmp(*argv, "encap-udp6-csum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_CSUM6;
+ } else if (strcmp(*argv, "noencap-udp6-csum") == 0) {
+ encapflags |= ~TUNNEL_ENCAP_FLAG_CSUM6;
} else
usage();
argc--; argv++;
@@ -271,6 +317,11 @@ get_failed:
addattr_l(n, 1024, IFLA_GRE_TTL, &ttl, 1);
addattr_l(n, 1024, IFLA_GRE_TOS, &tos, 1);
+ addattr16(n, 1024, IFLA_GRE_ENCAP_TYPE, encaptype);
+ addattr16(n, 1024, IFLA_GRE_ENCAP_FLAGS, encapflags);
+ addattr16(n, 1024, IFLA_GRE_ENCAP_SPORT, htons(encapsport));
+ addattr16(n, 1024, IFLA_GRE_ENCAP_DPORT, htons(encapdport));
+
return 0;
}
@@ -357,6 +408,44 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
fputs("icsum ", f);
if (oflags & GRE_CSUM)
fputs("ocsum ", f);
+
+ if (tb[IFLA_GRE_ENCAP_TYPE] &&
+ *(__u16 *)RTA_DATA(tb[IFLA_GRE_ENCAP_TYPE]) != TUNNEL_ENCAP_NONE) {
+ __u16 type = rta_getattr_u16(tb[IFLA_GRE_ENCAP_TYPE]);
+ __u16 flags = rta_getattr_u16(tb[IFLA_GRE_ENCAP_FLAGS]);
+ __u16 sport = rta_getattr_u16(tb[IFLA_GRE_ENCAP_SPORT]);
+ __u16 dport = rta_getattr_u16(tb[IFLA_GRE_ENCAP_DPORT]);
+
+ fputs("encap ", f);
+ switch (type) {
+ case TUNNEL_ENCAP_FOU:
+ fputs("fou ", f);
+ break;
+ case TUNNEL_ENCAP_GUE:
+ fputs("gue ", f);
+ break;
+ default:
+ fputs("unknown ", f);
+ break;
+ }
+
+ if (sport == 0)
+ fputs("encap-sport auto ", f);
+ else
+ fprintf(f, "encap-sport %u", ntohs(sport));
+
+ fprintf(f, "encap-dport %u ", ntohs(dport));
+
+ if (flags & TUNNEL_ENCAP_FLAG_CSUM)
+ fputs("encap-csum ", f);
+ else
+ fputs("noencap-csum ", f);
+
+ if (flags & TUNNEL_ENCAP_FLAG_CSUM6)
+ fputs("encap-csum6 ", f);
+ else
+ fputs("noencap-csum6 ", f);
+ }
}
static void gre_print_help(struct link_util *lu, int argc, char **argv,
--
2.1.0.rc2.206.gedb03e5
^ 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