* Re: [PATCH] selftests: bpf: add check for ip XDP redirect
From: William Tu @ 2017-08-11 13:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Linux Kernel Network Developers, John Fastabend
In-Reply-To: <598D9597.2030907@iogearbox.net>
thanks! I will fix it and re-submit.
William
On Fri, Aug 11, 2017 at 4:31 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 08/11/2017 02:02 AM, William Tu wrote:
>>
>> Kernel test robot reports error when running test_xdp_redirect.sh.
>> Check if ip tool supports xdpgeneric, if not, skip the test.
>>
>> Signed-off-by: William Tu <u9012063@gmail.com>
>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>> Cc: John Fastabend <john.fastabend@gmail.com>
>> ---
>> tools/testing/selftests/bpf/test_xdp_redirect.sh | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/tools/testing/selftests/bpf/test_xdp_redirect.sh
>> b/tools/testing/selftests/bpf/test_xdp_redirect.sh
>> index d8c73ed6e040..c5a8b7173c12 100755
>> --- a/tools/testing/selftests/bpf/test_xdp_redirect.sh
>> +++ b/tools/testing/selftests/bpf/test_xdp_redirect.sh
>> @@ -23,6 +23,11 @@ cleanup()
>> ip netns del ns2 2> /dev/null
>> }
>>
>> +ip link set dev lo xdpgeneric off 2>/dev/null > /dev/null
>> +if [ $? -ne 0 ];then
>> + echo "selftests: [SKIP] Could not run test without the ip
>> xdpgeneric support"
>> + exit 0
>
>
> Small nit: could you make that indent consistently as tabs
> like in your cleanup() function slightly further above?
>
> Other than that (+ subject should also be [PATCH net-next]):
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH v2] net: phy: Use tab for indentation in Kconfig
From: Andrew Lunn @ 2017-08-11 13:33 UTC (permalink / raw)
To: Michal Simek; +Cc: linux-kernel, monstr, David Miller, netdev, Florian Fainelli
In-Reply-To: <1b8d37ce323728c072e08f5683f2421f62fa297c.1502455731.git.michal.simek@xilinx.com>
On Fri, Aug 11, 2017 at 02:48:53PM +0200, Michal Simek wrote:
> Using tabs instead of space for indentaion
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Hi Michal
Thanks for rebasing.
FYI:
It is normal to put net-next in the patch subject to indicate this:
[Patch v2 net-next] Using tabs instead of space for indentaion
Ah! I just noticed. 'indentation' has a second T.
Andrew
^ permalink raw reply
* Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY
From: Corentin Labbe @ 2017-08-11 13:25 UTC (permalink / raw)
To: Chen-Yu Tsai, robh+dt, mark.rutland, f.fainelli
Cc: Russell King, Maxime Ripard, Giuseppe Cavallaro, alexandre.torgue,
netdev, devicetree, linux-kernel, linux-arm-kernel, andrew
In-Reply-To: <CAGb2v66SGAKnFoHNqWR+DqS-mY3KA853NmKpdHqf8huOkisLKg@mail.gmail.com>
On Fri, Aug 11, 2017 at 04:22:11PM +0800, Chen-Yu Tsai wrote:
> On Fri, Aug 11, 2017 at 4:19 PM, Corentin Labbe
> <clabbe.montjoie@gmail.com> wrote:
> > On Fri, Aug 11, 2017 at 04:11:13PM +0800, Chen-Yu Tsai wrote:
> >> On Fri, Aug 11, 2017 at 4:05 PM, Corentin Labbe
> >> <clabbe.montjoie@gmail.com> wrote:
> >> > On Fri, Aug 11, 2017 at 10:42:51AM +0800, Chen-Yu Tsai wrote:
> >> >> Hi,
> >> >>
> >> >> On Thu, Aug 10, 2017 at 4:51 PM, Corentin Labbe
> >> >> <clabbe.montjoie@gmail.com> wrote:
> >> >> > This patch add the new phy-is-integrated property to the internal PHY
> >> >> > node.
> >> >> >
> >> >> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> >> >> > ---
> >> >> > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
> >> >> > 1 file changed, 1 insertion(+)
> >> >> >
> >> >> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> >> > index 4b599b5d26f6..54fc24e4c569 100644
> >> >> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> >> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> >> > @@ -425,6 +425,7 @@
> >> >> > reg = <1>;
> >> >> > clocks = <&ccu CLK_BUS_EPHY>;
> >> >> > resets = <&ccu RST_BUS_EPHY>;
> >> >> > + phy-is-integrated;
> >> >>
> >> >> You also need to "delete" this property at the board level for
> >> >> any board that has the external PHY at address <1>. Otherwise
> >> >> they will stop working. This is due to the internal and external
> >> >> PHYs having the same path and node name in the device tree, so
> >> >> they are effectively the same node.
> >> >>
> >> >> ChenYu
> >> >>
> >> >
> >> > They have not the same name, ext_rgmii_phy vs int_mii_phy.
> >>
> >> That is just the label. The label plays no part in device tree merging. The path
> >>
> >> /soc/ethernet@1c30000/mdio/ethernet-phy@1
> >>
> >> is the same. You can look under
> >>
> >> /proc/device-tree/soc/ethernet@1c30000/mdio
> >>
> >> on the OrangePI Plus 2E or any other H3 board that uses an
> >> external PHY at address 1.
> >>
> >> ChenYu
> >
> > Since we get the phy node by phy-handle and not by path, I think all should be good.
>
> You are not getting me. The fact that the two seemingly separate
> nodes are merged together means, whatever properties you put in
> the internal PHY node, also affect the external PHY node. Once
> compiled, they are the SAME node.
Hello Rob, florian, mark
Adding a delete property on all external ethernet-phy@1 is a bit overkill, and I dont like the idea that nodes are merged.
What do you think about other possible solutions:
- Using integrated-phy@1 for the integrated PHY node name
- Using a fake address like 31 (see patch below)
If you have any other solution...
Regards
>From fe39183946f7f4a6e21bce38fd8e4c1413012d68 Mon Sep 17 00:00:00 2001
From: Corentin Labbe <clabbe.montjoie@gmail.com>
Date: Fri, 11 Aug 2017 14:49:54 +0200
Subject: [PATCH] ARM: sun8i: sunxi-h3-h5: Prevent merge of external and
integrated PHY
Actually, some external and integrated PHY are merged due to same dtnode
name "ethernet-phy@1".
This is problematic when we will want to use the phy-is-integrated
property. (Need to delete it on all external PHY node)
An easy solution is to set integrated PHY nodeaddresss at a fake one
that would never be used.
Since board makers currently only provides PHY at addresses 1 and 7,
we will use 31.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 54fc24e4c569..2110b0069e33 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -420,7 +420,15 @@
mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
- int_mii_phy: ethernet-phy@1 {
+ /*
+ * Using 31 permits to make a separation between
+ * this integrated PHY and external ones.
+ * Without it, external "ethernet-phy@1" will be
+ * merged with it (due to same dtnode name).
+ * Board makers currently only provides PHY at
+ * addresses 1 and 7.
+ */
+ int_mii_phy: ethernet-phy@31 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
clocks = <&ccu CLK_BUS_EPHY>;
--
2.13.0
^ permalink raw reply related
* Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers
From: Kalle Valo @ 2017-08-11 13:14 UTC (permalink / raw)
To: Andreas Born
Cc: Arend van Spriel, Mahesh Bandewar, Andy Gospodarek, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, James Feeney
In-Reply-To: <CADps9UA7S2betC-+5sOXjYWmDC8gnk6JJ9aEueEOoYAC3DU8hg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Andreas Born <futur.andy-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
> Earlier today I submitted the patch (bonding: require speed/duplex
> only for 802.3ad, alb and tlb) [2] that only partially reverts what is
> a regression following my aforementioned logic. This seems to me like
> the best solution in the short term since it should satisfy both
> usergroups represented by Mahesh and James and restores consistence
> with the bonding documentation. James already commented approvingly on
> that patch in the bug report. [3]
>
> Regards
> Andreas
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/bonding.txt
Great, thanks.
I'll take it the patch is meant for net tree (and not net-next) so that
it will be fixed for v4.13? Also it should backported to v4.12 stable
tree. I don't see any mention of that in the patch submission and that's
why I'm asking.
--
Kalle Valo
^ permalink raw reply
* [PATCH] mISDN: Fix null pointer dereference at mISDN_FsmNew
From: Anton Vasilyev @ 2017-08-11 12:57 UTC (permalink / raw)
To: Karsten Keil
Cc: Anton Vasilyev, Geliang Tang, David S. Miller, Johannes Berg,
Stephen Hemminger, netdev, linux-kernel, ldv-project
If mISDN_FsmNew() fails to allocate memory for jumpmatrix
then null pointer dereference will occur on any write to
jumpmatrix.
The patch adds check on successful allocation and
corresponding error handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
---
drivers/isdn/mISDN/fsm.c | 5 ++++-
drivers/isdn/mISDN/fsm.h | 2 +-
drivers/isdn/mISDN/layer1.c | 3 +--
drivers/isdn/mISDN/layer2.c | 15 +++++++++++++--
drivers/isdn/mISDN/tei.c | 20 +++++++++++++++++---
5 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/drivers/isdn/mISDN/fsm.c b/drivers/isdn/mISDN/fsm.c
index 78fc5d5..92e6570 100644
--- a/drivers/isdn/mISDN/fsm.c
+++ b/drivers/isdn/mISDN/fsm.c
@@ -26,7 +26,7 @@
#define FSM_TIMER_DEBUG 0
-void
+int
mISDN_FsmNew(struct Fsm *fsm,
struct FsmNode *fnlist, int fncount)
{
@@ -34,6 +34,8 @@ mISDN_FsmNew(struct Fsm *fsm,
fsm->jumpmatrix = kzalloc(sizeof(FSMFNPTR) * fsm->state_count *
fsm->event_count, GFP_KERNEL);
+ if (fsm->jumpmatrix == NULL)
+ return -ENOMEM;
for (i = 0; i < fncount; i++)
if ((fnlist[i].state >= fsm->state_count) ||
@@ -45,6 +47,7 @@ mISDN_FsmNew(struct Fsm *fsm,
} else
fsm->jumpmatrix[fsm->state_count * fnlist[i].event +
fnlist[i].state] = (FSMFNPTR) fnlist[i].routine;
+ return 0;
}
EXPORT_SYMBOL(mISDN_FsmNew);
diff --git a/drivers/isdn/mISDN/fsm.h b/drivers/isdn/mISDN/fsm.h
index 928f5be..e1def84 100644
--- a/drivers/isdn/mISDN/fsm.h
+++ b/drivers/isdn/mISDN/fsm.h
@@ -55,7 +55,7 @@ struct FsmTimer {
void *arg;
};
-extern void mISDN_FsmNew(struct Fsm *, struct FsmNode *, int);
+extern int mISDN_FsmNew(struct Fsm *, struct FsmNode *, int);
extern void mISDN_FsmFree(struct Fsm *);
extern int mISDN_FsmEvent(struct FsmInst *, int , void *);
extern void mISDN_FsmChangeState(struct FsmInst *, int);
diff --git a/drivers/isdn/mISDN/layer1.c b/drivers/isdn/mISDN/layer1.c
index bebc57b..3192b0e 100644
--- a/drivers/isdn/mISDN/layer1.c
+++ b/drivers/isdn/mISDN/layer1.c
@@ -414,8 +414,7 @@ l1_init(u_int *deb)
l1fsm_s.event_count = L1_EVENT_COUNT;
l1fsm_s.strEvent = strL1Event;
l1fsm_s.strState = strL1SState;
- mISDN_FsmNew(&l1fsm_s, L1SFnList, ARRAY_SIZE(L1SFnList));
- return 0;
+ return mISDN_FsmNew(&l1fsm_s, L1SFnList, ARRAY_SIZE(L1SFnList));
}
void
diff --git a/drivers/isdn/mISDN/layer2.c b/drivers/isdn/mISDN/layer2.c
index 7243a67..9ff0903 100644
--- a/drivers/isdn/mISDN/layer2.c
+++ b/drivers/isdn/mISDN/layer2.c
@@ -2247,15 +2247,26 @@ static struct Bprotocol X75SLP = {
int
Isdnl2_Init(u_int *deb)
{
+ int res;
debug = deb;
mISDN_register_Bprotocol(&X75SLP);
l2fsm.state_count = L2_STATE_COUNT;
l2fsm.event_count = L2_EVENT_COUNT;
l2fsm.strEvent = strL2Event;
l2fsm.strState = strL2State;
- mISDN_FsmNew(&l2fsm, L2FnList, ARRAY_SIZE(L2FnList));
- TEIInit(deb);
+ res = mISDN_FsmNew(&l2fsm, L2FnList, ARRAY_SIZE(L2FnList));
+ if (res)
+ goto error;
+ res = TEIInit(deb);
+ if (res)
+ goto error_fsm;
return 0;
+
+error_fsm:
+ mISDN_FsmFree(&l2fsm);
+error:
+ mISDN_unregister_Bprotocol(&X75SLP);
+ return res;
}
void
diff --git a/drivers/isdn/mISDN/tei.c b/drivers/isdn/mISDN/tei.c
index 908127e..12d9e5f 100644
--- a/drivers/isdn/mISDN/tei.c
+++ b/drivers/isdn/mISDN/tei.c
@@ -1387,23 +1387,37 @@ create_teimanager(struct mISDNdevice *dev)
int TEIInit(u_int *deb)
{
+ int res;
debug = deb;
teifsmu.state_count = TEI_STATE_COUNT;
teifsmu.event_count = TEI_EVENT_COUNT;
teifsmu.strEvent = strTeiEvent;
teifsmu.strState = strTeiState;
- mISDN_FsmNew(&teifsmu, TeiFnListUser, ARRAY_SIZE(TeiFnListUser));
+ res = mISDN_FsmNew(&teifsmu, TeiFnListUser, ARRAY_SIZE(TeiFnListUser));
+ if (res)
+ goto error;
teifsmn.state_count = TEI_STATE_COUNT;
teifsmn.event_count = TEI_EVENT_COUNT;
teifsmn.strEvent = strTeiEvent;
teifsmn.strState = strTeiState;
- mISDN_FsmNew(&teifsmn, TeiFnListNet, ARRAY_SIZE(TeiFnListNet));
+ res = mISDN_FsmNew(&teifsmn, TeiFnListNet, ARRAY_SIZE(TeiFnListNet));
+ if (res)
+ goto error_smn;
deactfsm.state_count = DEACT_STATE_COUNT;
deactfsm.event_count = DEACT_EVENT_COUNT;
deactfsm.strEvent = strDeactEvent;
deactfsm.strState = strDeactState;
- mISDN_FsmNew(&deactfsm, DeactFnList, ARRAY_SIZE(DeactFnList));
+ res = mISDN_FsmNew(&deactfsm, DeactFnList, ARRAY_SIZE(DeactFnList));
+ if (res)
+ goto error_deact;
return 0;
+
+error_deact:
+ mISDN_FsmFree(&teifsmn);
+error_smn:
+ mISDN_FsmFree(&teifsmu);
+error:
+ return res;
}
void TEIFree(void)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] drivers: add vpls support
From: David Lamparter @ 2017-08-11 12:55 UTC (permalink / raw)
To: Amine Kherbouche; +Cc: netdev, roopa
In-Reply-To: <1502396917-14848-3-git-send-email-amine.kherbouche@6wind.com>
On Thu, Aug 10, 2017 at 10:28:37PM +0200, Amine Kherbouche wrote:
> This commit introduces the support of VPLS virtual device, that allows
> performing L2VPN multipoint to multipoint communication over MPLS PSN.
>
> VPLS device encap received ethernet frame over mpls packet and send it the
> output device, in the other direction, when receiving the right configured
> mpls packet, the matched mpls route calls the handler vpls function,
> then pulls out the mpls header and send it back the entry point via
> netif_rx().
>
> Two functions, mpls_entry_encode() and mpls_output_possible() are
> exported from mpls/internal.h to be able to use them inside vpls driver.
>
> Signed-off-by: Amine Kherbouche <amine.kherbouche@6wind.com>
This code is derivative of code that I authored; while you
significantly changed it I'd appreciate if you kept a hint of that.
Unfortunately, I also have some concerns with this patch...
> +#define VPLS_MAX_ID 256 /* Max VPLS WireID (arbitrary) */
There is no point in keeping a VPLS wire ID. Again, this was in the
README that accompanied my patchset:
- I made a design mistake with the wire ID. It's simply not needed. A
pseudowire can be identified by its incoming label. There is also some
really ugly code keeping an array of wires...
I don't even see where you're using the wire ID anymore at this point,
it might be a dead leftover from my code.
[...]
> +union vpls_nh {
> + struct in6_addr addr6;
> + struct in_addr addr;
> +};
> +
> +struct vpls_dst {
> + struct net_device *dev;
> + union vpls_nh addr;
> + u32 label_in, label_out;
> + u32 id;
> + u16 vlan_id;
I looked at VLAN support and decided against it because the bridge layer
can handle this perfectly fine by using the bridge's vlan support to tag
a port's pvid.
> + u8 via_table;
> + u8 flags;
> + u8 ttl;
> +};
[...]
> +struct vpls_priv {
> + struct net *encap_net;
> + struct vpls_dst dst;
> +};
> +
> +static struct nla_policy vpls_policy[IFLA_VPLS_MAX + 1] = {
> + [IFLA_VPLS_ID] = { .type = NLA_U32 },
> + [IFLA_VPLS_IN_LABEL] = { .type = NLA_U32 },
> + [IFLA_VPLS_OUT_LABEL] = { .type = NLA_U32 },
> + [IFLA_VPLS_OIF] = { .type = NLA_U32 },
> + [IFLA_VPLS_TTL] = { .type = NLA_U8 },
> + [IFLA_VPLS_VLANID] = { .type = NLA_U8 },
> + [IFLA_VPLS_NH] = { .type = NLA_U32 },
> + [IFLA_VPLS_NH6] = { .len = sizeof(struct in6_addr) },
> +};
The original patchset was point-to-multipoint in a single netdev, and
had some starts on optimized multicast support (which, admittedly, is a
bit of a fringe thing, but still.)
This patch implements a single pseudowire (so the name is kind of
misleading; it's a VLL / VPWS, multiple of which you'd use to build full
VPLS). However, you are now missing split-horizon ethernet bridging
support. How is that done here?
-David
P.S.: for anyone curious, the original patchset is at
https://github.com/eqvinox/vpls-linux-kernel
I didn't go ahead with posting it because I felt there were several
things where I'd want to change the design, hence this README:
https://github.com/eqvinox/vpls-linux-kernel/commit/81c809d6f9c40c0332098e13fcad65144aa51795
^ permalink raw reply
* Re: [PATCH] net: phy: Use tab for indentation in Kconfig
From: Michal Simek @ 2017-08-11 12:50 UTC (permalink / raw)
To: David Miller, michal.simek
Cc: linux-kernel, monstr, netdev, andrew, f.fainelli
In-Reply-To: <20170808.210537.1599851067118765908.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 762 bytes --]
On 9.8.2017 06:05, David Miller wrote:
> From: Michal Simek <michal.simek@xilinx.com>
> Date: Tue, 8 Aug 2017 11:32:25 +0200
>
>> Using tabs instead of space for indentaion
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>
> This really isn't appropriate for the 'net' tree, it doesn't fix
> anything it just makes the spacing consistent.
>
> Please respin this patch against net-next, thank you.
v2 sent rebased on the top of net-next.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v2] net: phy: Use tab for indentation in Kconfig
From: Michal Simek @ 2017-08-11 12:48 UTC (permalink / raw)
To: linux-kernel, monstr; +Cc: David Miller, netdev, Andrew Lunn, Florian Fainelli
Using tabs instead of space for indentaion
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Changes in v2:
- Rebased on the top of net-next.
HEAD commit: 3b2b69efeca734b78bc85fd02253b0465bb2bec7
Suggested by David Miller
drivers/net/phy/Kconfig | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index bf73969a9d2b..81683a9677e9 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -5,7 +5,7 @@
menuconfig MDIO_DEVICE
tristate "MDIO bus device drivers"
help
- MDIO devices and driver infrastructure code.
+ MDIO devices and driver infrastructure code.
config MDIO_BUS
tristate
@@ -117,11 +117,11 @@ config MDIO_I2C
This is library mode.
config MDIO_MOXART
- tristate "MOXA ART MDIO interface support"
- depends on ARCH_MOXART
- help
- This driver supports the MDIO interface found in the network
- interface units of the MOXA ART SoC
+ tristate "MOXA ART MDIO interface support"
+ depends on ARCH_MOXART
+ help
+ This driver supports the MDIO interface found in the network
+ interface units of the MOXA ART SoC
config MDIO_OCTEON
tristate "Octeon and some ThunderX SOCs MDIO buses"
@@ -192,7 +192,7 @@ config LED_TRIGGER_PHY
state change will trigger the events, for consumption by an
LED class driver. There are triggers for each link speed currently
supported by the phy, and are of the form:
- <mii bus id>:<phy>:<speed>
+ <mii bus id>:<phy>:<speed>
Where speed is in the form:
<Speed in megabits>Mbps or <Speed in gigabits>Gbps
@@ -211,9 +211,9 @@ config AMD_PHY
Currently supports the am79c874
config AQUANTIA_PHY
- tristate "Aquantia PHYs"
- ---help---
- Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405
+ tristate "Aquantia PHYs"
+ ---help---
+ Currently supports the Aquantia AQ1202, AQ2104, AQR105, AQR405
config AT803X_PHY
tristate "AT803X PHYs"
@@ -377,21 +377,21 @@ config STE10XP
This is the driver for the STe100p and STe101p PHYs.
config TERANETICS_PHY
- tristate "Teranetics PHYs"
- ---help---
- Currently supports the Teranetics TN2020
+ tristate "Teranetics PHYs"
+ ---help---
+ Currently supports the Teranetics TN2020
config VITESSE_PHY
- tristate "Vitesse PHYs"
- ---help---
- Currently supports the vsc8244
+ tristate "Vitesse PHYs"
+ ---help---
+ Currently supports the vsc8244
config XILINX_GMII2RGMII
- tristate "Xilinx GMII2RGMII converter driver"
- ---help---
- This driver support xilinx GMII to RGMII IP core it provides
- the Reduced Gigabit Media Independent Interface(RGMII) between
- Ethernet physical media devices and the Gigabit Ethernet controller.
+ tristate "Xilinx GMII2RGMII converter driver"
+ ---help---
+ This driver support xilinx GMII to RGMII IP core it provides
+ the Reduced Gigabit Media Independent Interface(RGMII) between
+ Ethernet physical media devices and the Gigabit Ethernet controller.
endif # PHYLIB
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] mpls: add handlers
From: David Lamparter @ 2017-08-11 12:34 UTC (permalink / raw)
To: Amine Kherbouche; +Cc: netdev, roopa, David Lamparter
In-Reply-To: <1502396917-14848-2-git-send-email-amine.kherbouche@6wind.com>
On Thu, Aug 10, 2017 at 10:28:36PM +0200, Amine Kherbouche wrote:
> Mpls handler allows creation/deletion of mpls routes without using
> rtnetlink. When an incoming mpls packet matches this route, the saved
> function handler is called.
Since I originally authored this patch, I have come to believe that it
might be unneccessarily complicated. It is unlikely that a lot of
different "handlers" will exist here; the only things I can think of
are VPLS support and BIER-MPLS multicast replication. I'm not saying
it's a bad idea, but, well, this was in the README that I gave to 6WIND
with this code:
...
MPLS layer:
- the "MPT_HANDLER" thing is probably overkill, it likely makes more sense to
tie in the VPLS code more directly.
...
-David
^ permalink raw reply
* [PATCH net-next V2 3/3] tap: XDP support
From: Jason Wang @ 2017-08-11 11:41 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: kubakici, Jason Wang
In-Reply-To: <1502451678-17358-1-git-send-email-jasowang@redhat.com>
This patch tries to implement XDP for tun. The implementation was
split into two parts:
- fast path: small and no gso packet. We try to do XDP at page level
before build_skb(). For XDP_TX, since creating/destroying queues
were completely under control of userspace, it was implemented
through generic XDP helper after skb has been built. This could be
optimized in the future.
- slow path: big or gso packet. We try to do it after skb was created
through generic XDP helpers.
Test were done through pktgen with small packets.
xdp1 test shows ~41.1% improvement:
Before: ~1.7Mpps
After: ~2.3Mpps
xdp_redirect to ixgbe shows ~60% improvement:
Before: ~0.8Mpps
After: ~1.38Mpps
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 142 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9736df4..5892284 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -73,6 +73,8 @@
#include <linux/seq_file.h>
#include <linux/uio.h>
#include <linux/skb_array.h>
+#include <linux/bpf.h>
+#include <linux/bpf_trace.h>
#include <linux/uaccess.h>
@@ -105,7 +107,8 @@ do { \
} while (0)
#endif
-#define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD)
+#define TUN_HEADROOM 256
+#define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD + TUN_HEADROOM)
/* TUN device flags */
@@ -224,6 +227,7 @@ struct tun_struct {
u32 flow_count;
u32 rx_batched;
struct tun_pcpu_stats __percpu *pcpu_stats;
+ struct bpf_prog __rcu *xdp_prog;
};
#ifdef CONFIG_TUN_VNET_CROSS_LE
@@ -590,6 +594,7 @@ static void tun_detach(struct tun_file *tfile, bool clean)
static void tun_detach_all(struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
+ struct bpf_prog *xdp_prog = rtnl_dereference(tun->xdp_prog);
struct tun_file *tfile, *tmp;
int i, n = tun->numqueues;
@@ -622,6 +627,9 @@ static void tun_detach_all(struct net_device *dev)
}
BUG_ON(tun->numdisabled != 0);
+ if (xdp_prog)
+ bpf_prog_put(xdp_prog);
+
if (tun->flags & IFF_PERSIST)
module_put(THIS_MODULE);
}
@@ -1008,6 +1016,46 @@ tun_net_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)
stats->tx_dropped = tx_dropped;
}
+static int tun_xdp_set(struct net_device *dev, struct bpf_prog *prog,
+ struct netlink_ext_ack *extack)
+{
+ struct tun_struct *tun = netdev_priv(dev);
+ struct bpf_prog *old_prog;
+
+ old_prog = rtnl_dereference(tun->xdp_prog);
+ rcu_assign_pointer(tun->xdp_prog, prog);
+ if (old_prog)
+ bpf_prog_put(old_prog);
+
+ return 0;
+}
+
+static u32 tun_xdp_query(struct net_device *dev)
+{
+ struct tun_struct *tun = netdev_priv(dev);
+ const struct bpf_prog *xdp_prog;
+
+ xdp_prog = rtnl_dereference(tun->xdp_prog);
+ if (xdp_prog)
+ return xdp_prog->aux->id;
+
+ return 0;
+}
+
+static int tun_xdp(struct net_device *dev, struct netdev_xdp *xdp)
+{
+ switch (xdp->command) {
+ case XDP_SETUP_PROG:
+ return tun_xdp_set(dev, xdp->prog, xdp->extack);
+ case XDP_QUERY_PROG:
+ xdp->prog_id = tun_xdp_query(dev);
+ xdp->prog_attached = !!xdp->prog_id;
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
static const struct net_device_ops tun_netdev_ops = {
.ndo_uninit = tun_net_uninit,
.ndo_open = tun_net_open,
@@ -1038,6 +1086,7 @@ static const struct net_device_ops tap_netdev_ops = {
.ndo_features_check = passthru_features_check,
.ndo_set_rx_headroom = tun_set_headroom,
.ndo_get_stats64 = tun_net_get_stats64,
+ .ndo_xdp = tun_xdp,
};
static void tun_flow_init(struct tun_struct *tun)
@@ -1217,16 +1266,22 @@ static bool tun_can_build_skb(struct tun_struct *tun, struct tun_file *tfile,
return true;
}
-static struct sk_buff *tun_build_skb(struct tun_file *tfile,
+static struct sk_buff *tun_build_skb(struct tun_struct *tun,
+ struct tun_file *tfile,
struct iov_iter *from,
- int len)
+ struct virtio_net_hdr *hdr,
+ int len, int *generic_xdp)
{
struct page_frag *alloc_frag = &tfile->alloc_frag;
struct sk_buff *skb;
+ struct bpf_prog *xdp_prog;
int buflen = SKB_DATA_ALIGN(len + TUN_RX_PAD) +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+ unsigned int delta = 0;
char *buf;
size_t copied;
+ bool xdp_xmit = false;
+ int err;
if (unlikely(!skb_page_frag_refill(buflen, alloc_frag, GFP_KERNEL)))
return ERR_PTR(-ENOMEM);
@@ -1238,16 +1293,77 @@ static struct sk_buff *tun_build_skb(struct tun_file *tfile,
if (copied != len)
return ERR_PTR(-EFAULT);
+ if (hdr->gso_type)
+ *generic_xdp = 1;
+ else
+ *generic_xdp = 0;
+
+ rcu_read_lock();
+ xdp_prog = rcu_dereference(tun->xdp_prog);
+ if (xdp_prog && !*generic_xdp) {
+ struct xdp_buff xdp;
+ void *orig_data;
+ u32 act;
+
+ xdp.data_hard_start = buf;
+ xdp.data = buf + TUN_RX_PAD;
+ xdp.data_end = xdp.data + len;
+ orig_data = xdp.data;
+ act = bpf_prog_run_xdp(xdp_prog, &xdp);
+
+ switch (act) {
+ case XDP_REDIRECT:
+ get_page(alloc_frag->page);
+ alloc_frag->offset += buflen;
+ err = xdp_do_redirect(tun->dev, &xdp, xdp_prog);
+ if (err)
+ goto err_redirect;
+ return NULL;
+ case XDP_TX:
+ xdp_xmit = true;
+ /* fall through */
+ case XDP_PASS:
+ delta = orig_data - xdp.data;
+ break;
+ default:
+ bpf_warn_invalid_xdp_action(act);
+ /* fall through */
+ case XDP_ABORTED:
+ trace_xdp_exception(tun->dev, xdp_prog, act);
+ /* fall through */
+ case XDP_DROP:
+ goto err_xdp;
+ }
+ }
+
skb = build_skb(buf, buflen);
- if (!skb)
+ if (!skb) {
+ rcu_read_unlock();
return ERR_PTR(-ENOMEM);
+ }
- skb_reserve(skb, TUN_RX_PAD);
- skb_put(skb, len);
+ skb_reserve(skb, TUN_RX_PAD - delta);
+ skb_put(skb, len + delta);
get_page(alloc_frag->page);
alloc_frag->offset += buflen;
+ if (xdp_xmit) {
+ skb->dev = tun->dev;
+ generic_xdp_tx(skb, xdp_prog);
+ rcu_read_lock();
+ return NULL;
+ }
+
+ rcu_read_unlock();
+
return skb;
+
+err_redirect:
+ put_page(alloc_frag->page);
+err_xdp:
+ rcu_read_unlock();
+ this_cpu_inc(tun->pcpu_stats->rx_dropped);
+ return NULL;
}
/* Get packet from user space buffer */
@@ -1266,6 +1382,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
bool zerocopy = false;
int err;
u32 rxhash;
+ int generic_xdp = 1;
if (!(tun->dev->flags & IFF_UP))
return -EIO;
@@ -1324,11 +1441,13 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
}
if (tun_can_build_skb(tun, tfile, len, noblock, zerocopy)) {
- skb = tun_build_skb(tfile, from, len);
+ skb = tun_build_skb(tun, tfile, from, &gso, len, &generic_xdp);
if (IS_ERR(skb)) {
this_cpu_inc(tun->pcpu_stats->rx_dropped);
return PTR_ERR(skb);
}
+ if (!skb)
+ return total_len;
} else {
if (!zerocopy) {
copylen = len;
@@ -1402,6 +1521,22 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
+ if (generic_xdp) {
+ struct bpf_prog *xdp_prog;
+ int ret;
+
+ rcu_read_lock();
+ xdp_prog = rcu_dereference(tun->xdp_prog);
+ if (xdp_prog) {
+ ret = do_xdp_generic(xdp_prog, skb);
+ if (ret != XDP_PASS) {
+ rcu_read_unlock();
+ return total_len;
+ }
+ }
+ rcu_read_unlock();
+ }
+
rxhash = __skb_get_hash_symmetric(skb);
#ifndef CONFIG_4KSTACKS
tun_rx_batched(tun, tfile, skb, more);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next V2 2/3] net: export some generic xdp helpers
From: Jason Wang @ 2017-08-11 11:41 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: kubakici, Jason Wang
In-Reply-To: <1502451678-17358-1-git-send-email-jasowang@redhat.com>
This patch tries to export some generic xdp helpers to drivers. This
can let driver to do XDP for a specific skb. This is useful for the
case when the packet is hard to be processed at page level directly
(e.g jumbo/GSO frame).
With this patch, there's no need for driver to forbid the XDP set when
configuration is not suitable. Instead, it can defer the XDP for
packets that is hard to be processed directly after skb is created.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 14 ++++++++------
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1d238d5..0f1c4cb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3243,6 +3243,8 @@ static inline void dev_consume_skb_any(struct sk_buff *skb)
__dev_kfree_skb_any(skb, SKB_REASON_CONSUMED);
}
+void generic_xdp_tx(struct sk_buff *skb, struct bpf_prog *xdp_prog);
+int do_xdp_generic(struct bpf_prog *xdp_prog, struct sk_buff *skb);
int netif_rx(struct sk_buff *skb);
int netif_rx_ni(struct sk_buff *skb);
int netif_receive_skb(struct sk_buff *skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 3f69f6e..1a6657a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3920,7 +3920,7 @@ static u32 netif_receive_generic_xdp(struct sk_buff *skb,
/* When doing generic XDP we have to bypass the qdisc layer and the
* network taps in order to match in-driver-XDP behavior.
*/
-static void generic_xdp_tx(struct sk_buff *skb, struct bpf_prog *xdp_prog)
+void generic_xdp_tx(struct sk_buff *skb, struct bpf_prog *xdp_prog)
{
struct net_device *dev = skb->dev;
struct netdev_queue *txq;
@@ -3941,13 +3941,12 @@ static void generic_xdp_tx(struct sk_buff *skb, struct bpf_prog *xdp_prog)
kfree_skb(skb);
}
}
+EXPORT_SYMBOL_GPL(generic_xdp_tx);
static struct static_key generic_xdp_needed __read_mostly;
-static int do_xdp_generic(struct sk_buff *skb)
+int do_xdp_generic(struct bpf_prog *xdp_prog, struct sk_buff *skb)
{
- struct bpf_prog *xdp_prog = rcu_dereference(skb->dev->xdp_prog);
-
if (xdp_prog) {
u32 act = netif_receive_generic_xdp(skb, xdp_prog);
int err;
@@ -3972,6 +3971,7 @@ static int do_xdp_generic(struct sk_buff *skb)
kfree_skb(skb);
return XDP_DROP;
}
+EXPORT_SYMBOL_GPL(do_xdp_generic);
static int netif_rx_internal(struct sk_buff *skb)
{
@@ -3982,7 +3982,8 @@ static int netif_rx_internal(struct sk_buff *skb)
trace_netif_rx(skb);
if (static_key_false(&generic_xdp_needed)) {
- int ret = do_xdp_generic(skb);
+ int ret = do_xdp_generic(rcu_dereference(skb->dev->xdp_prog),
+ skb);
/* Consider XDP consuming the packet a success from
* the netdev point of view we do not want to count
@@ -4503,7 +4504,8 @@ static int netif_receive_skb_internal(struct sk_buff *skb)
rcu_read_lock();
if (static_key_false(&generic_xdp_needed)) {
- int ret = do_xdp_generic(skb);
+ int ret = do_xdp_generic(rcu_dereference(skb->dev->xdp_prog),
+ skb);
if (ret != XDP_PASS) {
rcu_read_unlock();
--
2.7.4
^ permalink raw reply related
* [PATCH net-next V2 1/3] tap: use build_skb() for small packet
From: Jason Wang @ 2017-08-11 11:41 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: kubakici, Jason Wang
In-Reply-To: <1502451678-17358-1-git-send-email-jasowang@redhat.com>
We use tun_alloc_skb() which calls sock_alloc_send_pskb() to allocate
skb in the past. This socket based method is not suitable for high
speed userspace like virtualization which usually:
- ignore sk_sndbuf (INT_MAX) and expect to receive the packet as fast as
possible
- don't want to be block at sendmsg()
To eliminate the above overheads, this patch tries to use build_skb()
for small packet. We will do this only when the following conditions
are all met:
- TAP instead of TUN
- sk_sndbuf is INT_MAX
- caller don't want to be blocked
- zerocopy is not used
- packet size is smaller enough to use build_skb()
Pktgen from guest to host shows ~11% improvement for rx pps of tap:
Before: ~1.70Mpps
After : ~1.88Mpps
What's more important, this makes it possible to implement XDP for tap
before creating skbs.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 112 ++++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 91 insertions(+), 21 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index d21510d..9736df4 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -105,6 +105,8 @@ do { \
} while (0)
#endif
+#define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD)
+
/* TUN device flags */
/* IFF_ATTACH_QUEUE is never stored in device flags,
@@ -170,6 +172,7 @@ struct tun_file {
struct list_head next;
struct tun_struct *detached;
struct skb_array tx_array;
+ struct page_frag alloc_frag;
};
struct tun_flow_entry {
@@ -571,6 +574,8 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
}
if (tun)
skb_array_cleanup(&tfile->tx_array);
+ if (tfile->alloc_frag.page)
+ put_page(tfile->alloc_frag.page);
sock_put(&tfile->sk);
}
}
@@ -1190,6 +1195,61 @@ static void tun_rx_batched(struct tun_struct *tun, struct tun_file *tfile,
}
}
+static bool tun_can_build_skb(struct tun_struct *tun, struct tun_file *tfile,
+ int len, int noblock, bool zerocopy)
+{
+ if ((tun->flags & TUN_TYPE_MASK) != IFF_TAP)
+ return false;
+
+ if (tfile->socket.sk->sk_sndbuf != INT_MAX)
+ return false;
+
+ if (!noblock)
+ return false;
+
+ if (zerocopy)
+ return false;
+
+ if (SKB_DATA_ALIGN(len + TUN_RX_PAD) +
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) > PAGE_SIZE)
+ return false;
+
+ return true;
+}
+
+static struct sk_buff *tun_build_skb(struct tun_file *tfile,
+ struct iov_iter *from,
+ int len)
+{
+ struct page_frag *alloc_frag = &tfile->alloc_frag;
+ struct sk_buff *skb;
+ int buflen = SKB_DATA_ALIGN(len + TUN_RX_PAD) +
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+ char *buf;
+ size_t copied;
+
+ if (unlikely(!skb_page_frag_refill(buflen, alloc_frag, GFP_KERNEL)))
+ return ERR_PTR(-ENOMEM);
+
+ buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
+ copied = copy_page_from_iter(alloc_frag->page,
+ alloc_frag->offset + TUN_RX_PAD,
+ len, from);
+ if (copied != len)
+ return ERR_PTR(-EFAULT);
+
+ skb = build_skb(buf, buflen);
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
+
+ skb_reserve(skb, TUN_RX_PAD);
+ skb_put(skb, len);
+ get_page(alloc_frag->page);
+ alloc_frag->offset += buflen;
+
+ return skb;
+}
+
/* Get packet from user space buffer */
static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
void *msg_control, struct iov_iter *from,
@@ -1263,30 +1323,38 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
zerocopy = true;
}
- if (!zerocopy) {
- copylen = len;
- if (tun16_to_cpu(tun, gso.hdr_len) > good_linear)
- linear = good_linear;
- else
- linear = tun16_to_cpu(tun, gso.hdr_len);
- }
-
- skb = tun_alloc_skb(tfile, align, copylen, linear, noblock);
- if (IS_ERR(skb)) {
- if (PTR_ERR(skb) != -EAGAIN)
+ if (tun_can_build_skb(tun, tfile, len, noblock, zerocopy)) {
+ skb = tun_build_skb(tfile, from, len);
+ if (IS_ERR(skb)) {
this_cpu_inc(tun->pcpu_stats->rx_dropped);
- return PTR_ERR(skb);
- }
+ return PTR_ERR(skb);
+ }
+ } else {
+ if (!zerocopy) {
+ copylen = len;
+ if (tun16_to_cpu(tun, gso.hdr_len) > good_linear)
+ linear = good_linear;
+ else
+ linear = tun16_to_cpu(tun, gso.hdr_len);
+ }
- if (zerocopy)
- err = zerocopy_sg_from_iter(skb, from);
- else
- err = skb_copy_datagram_from_iter(skb, 0, from, len);
+ skb = tun_alloc_skb(tfile, align, copylen, linear, noblock);
+ if (IS_ERR(skb)) {
+ if (PTR_ERR(skb) != -EAGAIN)
+ this_cpu_inc(tun->pcpu_stats->rx_dropped);
+ return PTR_ERR(skb);
+ }
- if (err) {
- this_cpu_inc(tun->pcpu_stats->rx_dropped);
- kfree_skb(skb);
- return -EFAULT;
+ if (zerocopy)
+ err = zerocopy_sg_from_iter(skb, from);
+ else
+ err = skb_copy_datagram_from_iter(skb, 0, from, len);
+
+ if (err) {
+ this_cpu_inc(tun->pcpu_stats->rx_dropped);
+ kfree_skb(skb);
+ return -EFAULT;
+ }
}
if (virtio_net_hdr_to_skb(skb, &gso, tun_is_little_endian(tun))) {
@@ -2377,6 +2445,8 @@ static int tun_chr_open(struct inode *inode, struct file * file)
tfile->sk.sk_write_space = tun_sock_write_space;
tfile->sk.sk_sndbuf = INT_MAX;
+ tfile->alloc_frag.page = NULL;
+
file->private_data = tfile;
INIT_LIST_HEAD(&tfile->next);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next V2 0/3] XDP support for tap
From: Jason Wang @ 2017-08-11 11:41 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: kubakici, Jason Wang
Hi all:
This series tries to implement XDP support for tap. Two path were
implemented:
- fast path: small & non-gso packet, For performance reason we do it
at page level and use build_skb() to create skb if necessary.
- slow path: big or gso packet, we don't want to lose the capability
compared to generic XDP, so we export some generic xdp helpers and
do it after skb was created.
xdp1 shows about 41% improvement, xdp_redirect shows about 60%
improvement.
Changes from V1:
- fix the race between xdp set and free
- don't hold extra refcount
- add XDP_REDIRECT support
Please review.
Jason Wang (3):
tap: use build_skb() for small packet
net: export some generic xdp helpers
tap: XDP support
drivers/net/tun.c | 247 ++++++++++++++++++++++++++++++++++++++++++----
include/linux/netdevice.h | 2 +
net/core/dev.c | 14 +--
3 files changed, 236 insertions(+), 27 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] selftests: bpf: add check for ip XDP redirect
From: Daniel Borkmann @ 2017-08-11 11:31 UTC (permalink / raw)
To: William Tu, netdev; +Cc: John Fastabend
In-Reply-To: <1502409753-27516-1-git-send-email-u9012063@gmail.com>
On 08/11/2017 02:02 AM, William Tu wrote:
> Kernel test robot reports error when running test_xdp_redirect.sh.
> Check if ip tool supports xdpgeneric, if not, skip the test.
>
> Signed-off-by: William Tu <u9012063@gmail.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: John Fastabend <john.fastabend@gmail.com>
> ---
> tools/testing/selftests/bpf/test_xdp_redirect.sh | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/test_xdp_redirect.sh b/tools/testing/selftests/bpf/test_xdp_redirect.sh
> index d8c73ed6e040..c5a8b7173c12 100755
> --- a/tools/testing/selftests/bpf/test_xdp_redirect.sh
> +++ b/tools/testing/selftests/bpf/test_xdp_redirect.sh
> @@ -23,6 +23,11 @@ cleanup()
> ip netns del ns2 2> /dev/null
> }
>
> +ip link set dev lo xdpgeneric off 2>/dev/null > /dev/null
> +if [ $? -ne 0 ];then
> + echo "selftests: [SKIP] Could not run test without the ip xdpgeneric support"
> + exit 0
Small nit: could you make that indent consistently as tabs
like in your cleanup() function slightly further above?
Other than that (+ subject should also be [PATCH net-next]):
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* [PATCH] openvswitch: Remove unnecessary newlines from OVS_NLERR uses
From: Joe Perches @ 2017-08-11 11:26 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David S. Miller, netdev, dev, linux-kernel
OVS_NLERR already adds a newline so these just add blank
lines to the logging.
Signed-off-by: Joe Perches <joe@perches.com>
---
net/openvswitch/conntrack.c | 14 +++++---------
net/openvswitch/flow_netlink.c | 2 +-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 03859e386b47..30d632509f82 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1180,15 +1180,13 @@ static int parse_nat(const struct nlattr *attr,
int type = nla_type(a);
if (type > OVS_NAT_ATTR_MAX) {
- OVS_NLERR(log,
- "Unknown NAT attribute (type=%d, max=%d).\n",
+ OVS_NLERR(log, "Unknown NAT attribute (type=%d, max=%d)",
type, OVS_NAT_ATTR_MAX);
return -EINVAL;
}
if (nla_len(a) != ovs_nat_attr_lens[type][ip_vers]) {
- OVS_NLERR(log,
- "NAT attribute type %d has unexpected length (%d != %d).\n",
+ OVS_NLERR(log, "NAT attribute type %d has unexpected length (%d != %d)",
type, nla_len(a),
ovs_nat_attr_lens[type][ip_vers]);
return -EINVAL;
@@ -1198,9 +1196,7 @@ static int parse_nat(const struct nlattr *attr,
case OVS_NAT_ATTR_SRC:
case OVS_NAT_ATTR_DST:
if (info->nat) {
- OVS_NLERR(log,
- "Only one type of NAT may be specified.\n"
- );
+ OVS_NLERR(log, "Only one type of NAT may be specified");
return -ERANGE;
}
info->nat |= OVS_CT_NAT;
@@ -1245,13 +1241,13 @@ static int parse_nat(const struct nlattr *attr,
break;
default:
- OVS_NLERR(log, "Unknown nat attribute (%d).\n", type);
+ OVS_NLERR(log, "Unknown nat attribute (%d)", type);
return -EINVAL;
}
}
if (rem > 0) {
- OVS_NLERR(log, "NAT attribute has %d unknown bytes.\n", rem);
+ OVS_NLERR(log, "NAT attribute has %d unknown bytes", rem);
return -EINVAL;
}
if (!info->nat) {
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index f07d10ac35d8..e8eb427ce6d1 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1255,7 +1255,7 @@ static int ovs_key_from_nlattrs(struct net *net, struct sw_flow_match *match,
}
if (!is_mask && ipv6_key->ipv6_label & htonl(0xFFF00000)) {
- OVS_NLERR(log, "IPv6 flow label %x is out of range (max=%x).\n",
+ OVS_NLERR(log, "IPv6 flow label %x is out of range (max=%x)",
ntohl(ipv6_key->ipv6_label), (1 << 20) - 1);
return -EINVAL;
}
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* INFO.......................
From: zama01 @ 2017-08-11 11:19 UTC (permalink / raw)
--
Greetings,
Can you handle a transaction that involves the transfer of fund valued
15 million Euros into a foreign account.I will give you the full
detailed information as soon as I hear from you
Ahmed Zama
UBA BANK
OUAGADOUGOU BURKINA FASO
^ permalink raw reply
* Re: [PATCH] bonding: ratelimit failed speed/duplex update warning
From: Joe Perches @ 2017-08-11 10:59 UTC (permalink / raw)
To: Andreas Born, netdev
In-Reply-To: <20170811100413.16234-1-futur.andy@googlemail.com>
On Fri, 2017-08-11 at 12:04 +0200, Andreas Born wrote:
> bond_miimon_commit() handles the UP transition for each slave of a bond
> in the case of MII. It is triggered 10 times per second for the default
> MII Polling interval of 100ms. For device drivers that do not implement
> __ethtool_get_link_ksettings() the call to bond_update_speed_duplex()
> fails persistently while the MII status could remain UP. That is, in this and
> other cases where the speed/duplex update keeps failing over a longer
> period of time while the MII state is UP, a warning is printed every MII
> polling interval.
>
> To address these excessive warnings pr_warn_ratelimited() should be used
> instead. pr_warn_once() would not be sufficient since the call to
> bond_update_speed_duplex() could recover to meanwhile succeed and fail
> again later.
[]
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
[]
> @@ -2144,9 +2144,9 @@ static void bond_miimon_commit(struct bonding *bond)
> if (bond_update_speed_duplex(slave) &&
> bond_needs_speed_duplex(bond)) {
> slave->link = BOND_LINK_DOWN;
> - netdev_warn(bond->dev,
> - "failed to get link speed/duplex for %s\n",
> - slave->dev->name);
> + pr_warn_ratelimited("%s: failed to get link speed/duplex for %s\n",
> + bond->dev->name,
> + slave->dev->name);
This is more commonly done using
if (net_ratelimit())
netdev_warn(etc...)
^ permalink raw reply
* [PATCHv3 2/2] drivers: net: davinci_mdio: print bus frequency
From: Max Uvarov @ 2017-08-11 10:57 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, grygorii.strashko, Max Uvarov
In-Reply-To: <1502449061-30373-1-git-send-email-muvarov@gmail.com>
Frequency can be adjusted in DT it make sense to
print current used value on driver init.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 611e7cc..3c33f45 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -159,8 +159,10 @@ static int davinci_mdio_reset(struct mii_bus *bus)
/* dump hardware version info */
ver = __raw_readl(&data->regs->version);
- dev_info(data->dev, "davinci mdio revision %d.%d\n",
- (ver >> 8) & 0xff, ver & 0xff);
+ dev_info(data->dev,
+ "davinci mdio revision %d.%d, bus freq %ld\n",
+ (ver >> 8) & 0xff, ver & 0xff,
+ data->pdata.bus_freq);
if (data->skip_scan)
goto done;
--
2.5.0
^ permalink raw reply related
* [PATCHv3 1/2] drivers: net: davinci_mdio: remove busy loop on wait user access
From: Max Uvarov @ 2017-08-11 10:57 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, grygorii.strashko, Max Uvarov
In-Reply-To: <1502449061-30373-1-git-send-email-muvarov@gmail.com>
Polling 14 mdio devices on single mdio bus eats 30% of 1Ghz cpu time
due to busy loop in wait(). Add small delay to relax cpu.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 33df340..611e7cc 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -198,8 +198,10 @@ static inline int wait_for_user_access(struct davinci_mdio_data *data)
return 0;
reg = __raw_readl(®s->control);
- if ((reg & CONTROL_IDLE) == 0)
+ if ((reg & CONTROL_IDLE) == 0) {
+ usleep_range(100, 200);
continue;
+ }
/*
* An emac soft_reset may have clobbered the mdio controller's
--
2.5.0
^ permalink raw reply related
* [PATCHv3 0/2] davinci_mdio: remove busy loop on wait user access
From: Max Uvarov @ 2017-08-11 10:57 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, grygorii.strashko, Max Uvarov
v3: no code change, just added cover letter
First patch fixes cpu load on polling busy mdio line.
Second patch just prints which mdio frequency was configured.
Max Uvarov (2):
drivers: net: davinci_mdio: remove busy loop on wait user access
drivers: net: davinci_mdio: print bus frequency
drivers/net/ethernet/ti/davinci_mdio.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
2.5.0
^ permalink raw reply
* Re: [PATCH ipsec-next] net: xfrm: support setting an output mark.
From: Steffen Klassert @ 2017-08-11 10:55 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: netdev, davem, jhs, herbert
In-Reply-To: <20170810171133.69254-1-lorenzo@google.com>
On Fri, Aug 11, 2017 at 02:11:33AM +0900, Lorenzo Colitti wrote:
> On systems that use mark-based routing it may be necessary for
> routing lookups to use marks in order for packets to be routed
> correctly. An example of such a system is Android, which uses
> socket marks to route packets via different networks.
>
> Currently, routing lookups in tunnel mode always use a mark of
> zero, making routing incorrect on such systems.
>
> This patch adds a new output_mark element to the xfrm state and
> a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
> mark differs from the existing xfrm mark in two ways:
>
> 1. The xfrm mark is used to match xfrm policies and states, while
> the xfrm output mark is used to set the mark (and influence
> the routing) of the packets emitted by those states.
> 2. The existing mark is constrained to be a subset of the bits of
> the originating socket or transformed packet, but the output
> mark is arbitrary and depends only on the state.
>
> The use of a separate mark provides additional flexibility. For
> example:
>
> - A packet subject to two transforms (e.g., transport mode inside
> tunnel mode) can have two different output marks applied to it,
> one for the transport mode SA and one for the tunnel mode SA.
> - On a system where socket marks determine routing, the packets
> emitted by an IPsec tunnel can be routed based on a mark that
> is determined by the tunnel, not by the marks of the
> unencrypted packets.
> - Support for setting the output marks can be introduced without
> breaking any existing setups that employ both mark-based
> routing and xfrm tunnel mode. Simply changing the code to use
> the xfrm mark for routing output packets could xfrm mark could
> change behaviour in a way that breaks these setups.
>
> If the output mark is unspecified or set to zero, the mark is not
> set or changed.
>
> Tested: make allyesconfig; make -j64
> Tested: https://android-review.googlesource.com/452776
> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Patch applied to ipsec-next, thanks Lorenzo!
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: enable NSH support
From: Jiri Pirko @ 2017-08-11 10:35 UTC (permalink / raw)
To: Jan Scheurich
Cc: Jiri Benc, Yang, Yi Y, netdev@vger.kernel.org,
dev@openvswitch.org
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D7273679A@ESESSMB107.ericsson.se>
Fri, Aug 11, 2017 at 12:09:36PM CEST, jan.scheurich@ericsson.com wrote:
>> -----Original Message-----
>> From: Jiri Benc [mailto:jbenc@redhat.com]
>> Sent: Friday, 11 August, 2017 11:45
>>
>> The context field does not apply to MD type 2. It looks wrong for the
>> context field to be included in netlink attribute for anything other
>> than MD type 1. Perhaps it needs to be put into a separate attribute,
>> too?
>>
>> Note that I'm talking only about the uAPI. Internally, ovs can use
>> struct ovs_key_nsh that is MD type 1 only, there's no problem changing
>> that later. But for the user space interface, this needs to be clean.
>> This can be solved for example this way:
>>
>> In include/uapi/linux/openvswitch.h:
>>
>> struct ovs_key_nsh_base {
>> __u8 flags;
>> __u8 mdtype;
>> __u8 np;
>> __u8 pad;
>> __be32 path_hdr;
>> };
>>
>> + one more netlink attribute carrying MD type 1 info. Will probably
>> require to change OVS_KEY_ATTR_NSH to a nested attribute etc.
>>
>> In net/openvswitch/flow.h (or perhaps a different header would be more
>> appropriate?):
>>
>> struct ovs_key_nsh {
>> struct ovs_key_nsh_base base;
>> __be32 context[4];
>> };
>>
>> Plus needed conversions between OVS_KEY_ATTR_NSH and struct ovs_key_nsh
>> when interfacing between the kernel and user space.
>>
>> That way, we can have MD type 1 support only for now while still being
>> allowed to redesign things in whatever way later.
>>
>> Jiri
>
>For the OVS_KEY_ATTR_NSH I agree to move the fixed size MD1 context headers from nsh_base to a separate struct and use nested netlink attributes.
>
>For OVS_ACTION_ATTR_PUSH_NSH attribute any metadata included is opaque to the datapath and should be copied as is into the packet header. I doubt that there is any benefit to model this with nested attributes for MD1 or MD2. This just adds complexity on sender and receiver side and requires updates in case there should be other MD types added later on.
>
>Unless someone can explain to me why the datapath should understand the internal structure/format of metadata in push_nsh, I would strongly vote to keep the metadata as variable length octet sequence in the non-structured OVS_ACTION_ATTR_PUSH_NSH
Could you please wrap lines at 72 chars? This is unreadable. Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: enable NSH support
From: Jiri Benc @ 2017-08-11 10:22 UTC (permalink / raw)
To: Jan Scheurich
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D7273679A-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
On Fri, 11 Aug 2017 10:09:36 +0000, Jan Scheurich wrote:
> Unless someone can explain to me why the datapath should understand the
> internal structure/format of metadata in push_nsh, I would strongly
> vote to keep the metadata as variable length octet sequence in the
> non-structured OVS_ACTION_ATTR_PUSH_NSH
Could be but it still needs to be in a different attribute and not in
the ovs_action_push_nsh structure.
Separate attributes for MD1/MD2 has the advantage of easier validation:
with a separate MD1 type attribute, the size check is easier. With an
unstructured MD attribute, we'd need to look into the
OVS_ACTION_ATTR_NSH_BASE_HEADER attribute for mdtype and then validate
the unstructured MD attribute size manually. Not a big deal, though.
I don't have strong opinion here.
But I do have strong opinion that MD needs to go into a separate
attribute, whether there are separate attributes for MD1/2 or not.
Jiri
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: enable NSH support
From: Jan Scheurich @ 2017-08-11 10:09 UTC (permalink / raw)
To: Jiri Benc, Yang, Yi Y
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170811114449.745c49c5@griffin>
> -----Original Message-----
> From: Jiri Benc [mailto:jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org]
> Sent: Friday, 11 August, 2017 11:45
>
> The context field does not apply to MD type 2. It looks wrong for the
> context field to be included in netlink attribute for anything other
> than MD type 1. Perhaps it needs to be put into a separate attribute,
> too?
>
> Note that I'm talking only about the uAPI. Internally, ovs can use
> struct ovs_key_nsh that is MD type 1 only, there's no problem changing
> that later. But for the user space interface, this needs to be clean.
> This can be solved for example this way:
>
> In include/uapi/linux/openvswitch.h:
>
> struct ovs_key_nsh_base {
> __u8 flags;
> __u8 mdtype;
> __u8 np;
> __u8 pad;
> __be32 path_hdr;
> };
>
> + one more netlink attribute carrying MD type 1 info. Will probably
> require to change OVS_KEY_ATTR_NSH to a nested attribute etc.
>
> In net/openvswitch/flow.h (or perhaps a different header would be more
> appropriate?):
>
> struct ovs_key_nsh {
> struct ovs_key_nsh_base base;
> __be32 context[4];
> };
>
> Plus needed conversions between OVS_KEY_ATTR_NSH and struct ovs_key_nsh
> when interfacing between the kernel and user space.
>
> That way, we can have MD type 1 support only for now while still being
> allowed to redesign things in whatever way later.
>
> Jiri
For the OVS_KEY_ATTR_NSH I agree to move the fixed size MD1 context headers from nsh_base to a separate struct and use nested netlink attributes.
For OVS_ACTION_ATTR_PUSH_NSH attribute any metadata included is opaque to the datapath and should be copied as is into the packet header. I doubt that there is any benefit to model this with nested attributes for MD1 or MD2. This just adds complexity on sender and receiver side and requires updates in case there should be other MD types added later on.
Unless someone can explain to me why the datapath should understand the internal structure/format of metadata in push_nsh, I would strongly vote to keep the metadata as variable length octet sequence in the non-structured OVS_ACTION_ATTR_PUSH_NSH
BR, Jan
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: enable NSH support
From: Yang, Yi @ 2017-08-11 9:54 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, dev
In-Reply-To: <20170811114449.745c49c5@griffin>
On Fri, Aug 11, 2017 at 11:44:49AM +0200, Jiri Benc wrote:
> On Fri, 11 Aug 2017 09:24:25 +0000, Yang, Yi Y wrote:
> > So far, we're not clear how we can support MD type 2 better, as I
> > explained before, we need to reuse tun_metadata in struct flow_tnl
> > which is the thing Geneve is using. Geneve predefined 64 keys for
> > this from tun_metadata0 to tun_metadata63, we will reuse it for MD
> > type 2. But you know NSH is not tunnel, so it has to be changed to
> > support both Geneve and NSH. Anyway, they won't be part of
> > ovs_key_nsh.
>
> Please do not top post.
Sorry for this inconvenience, I'm using outlook. But now I have to use
mutt to address your concern :-)
>
> The context field does not apply to MD type 2. It looks wrong for the
> context field to be included in netlink attribute for anything other
> than MD type 1. Perhaps it needs to be put into a separate attribute,
> too?
>
> Note that I'm talking only about the uAPI. Internally, ovs can use
> struct ovs_key_nsh that is MD type 1 only, there's no problem changing
> that later. But for the user space interface, this needs to be clean.
> This can be solved for example this way:
>
> In include/uapi/linux/openvswitch.h:
>
> struct ovs_key_nsh_base {
> __u8 flags;
> __u8 mdtype;
> __u8 np;
> __u8 pad;
> __be32 path_hdr;
> };
>
> + one more netlink attribute carrying MD type 1 info. Will probably
> require to change OVS_KEY_ATTR_NSH to a nested attribute etc.
>
> In net/openvswitch/flow.h (or perhaps a different header would be more
> appropriate?):
>
> struct ovs_key_nsh {
> struct ovs_key_nsh_base base;
> __be32 context[4];
> };
>
> Plus needed conversions between OVS_KEY_ATTR_NSH and struct ovs_key_nsh
> when interfacing between the kernel and user space.
>
> That way, we can have MD type 1 support only for now while still being
> allowed to redesign things in whatever way later.
Yeah, good suggestion, will try to do that way.
>
> Jiri
^ permalink raw reply
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