* [net-next 13/15] igb: Indicate failure on vf reset for empty mac address
From: Jeff Kirsher @ 2015-01-23 2:37 UTC (permalink / raw)
To: davem; +Cc: Alexander Graf, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1421980631-1955-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Graf <agraf@suse.de>
Commit 5ac6f91d changed the igb driver to expose a zero (empty) mac
address to the VF on reset rather than a random one.
However, that behavioral change also requires igbvf driver changes
which can be hard especially when we want to talk to proprietary
guest OSs.
Looking at the code previous to the commit in Linux that made igbvf
work with empty mac addresses (8d56b6d), we can see that on reset
failure the driver will try to generate a new mac address with both
the old and the new code.
Furthermore, ixgbe does send reset failure when it detects an empty
mac address (35055928c).
So I think it's safe to make igb behave the same. With this patch I
can successfully run a Windows 8.1 guest with an empty mac address
and an assigned igbvf device that has no mac address set by the host.
If anyone is aware of a guest driver that chokes on NACK returns of
VF RESET commands, please speak up.
Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 6e65449..f366b3b 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6077,8 +6077,12 @@ static void igb_vf_reset_msg(struct igb_adapter *adapter, u32 vf)
adapter->vf_data[vf].flags |= IGB_VF_FLAG_CTS;
/* reply to reset with ack and vf mac address */
- msgbuf[0] = E1000_VF_RESET | E1000_VT_MSGTYPE_ACK;
- memcpy(addr, vf_mac, ETH_ALEN);
+ if (!is_zero_ether_addr(vf_mac)) {
+ msgbuf[0] = E1000_VF_RESET | E1000_VT_MSGTYPE_ACK;
+ memcpy(addr, vf_mac, ETH_ALEN);
+ } else {
+ msgbuf[0] = E1000_VF_RESET | E1000_VT_MSGTYPE_NACK;
+ }
igb_write_mbx(hw, msgbuf, 3, vf);
}
--
1.9.3
^ permalink raw reply related
* [net-next 14/15] net: e1000: support txtd update delay via xmit_more
From: Jeff Kirsher @ 2015-01-23 2:37 UTC (permalink / raw)
To: davem; +Cc: Florian Westphal, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1421980631-1955-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Florian Westphal <fw@strlen.de>
Don't update Tx tail descriptor if we queue hasn't been stopped and
we know at least one more skb will be sent right away.
Signed-off-by: Florian Westphal <fw@strlen.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 9242982..7f997d3 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -2977,7 +2977,6 @@ static void e1000_tx_queue(struct e1000_adapter *adapter,
struct e1000_tx_ring *tx_ring, int tx_flags,
int count)
{
- struct e1000_hw *hw = &adapter->hw;
struct e1000_tx_desc *tx_desc = NULL;
struct e1000_tx_buffer *buffer_info;
u32 txd_upper = 0, txd_lower = E1000_TXD_CMD_IFCS;
@@ -3031,11 +3030,6 @@ static void e1000_tx_queue(struct e1000_adapter *adapter,
wmb();
tx_ring->next_to_use = i;
- writel(i, hw->hw_addr + tx_ring->tdt);
- /* we need this if more than one processor can write to our tail
- * at a time, it synchronizes IO on IA64/Altix systems
- */
- mmiowb();
}
/* 82547 workaround to avoid controller hang in half-duplex environment.
@@ -3264,6 +3258,15 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
/* Make sure there is space in the ring for the next send. */
e1000_maybe_stop_tx(netdev, tx_ring, MAX_SKB_FRAGS + 2);
+ if (!skb->xmit_more ||
+ netif_xmit_stopped(netdev_get_tx_queue(netdev, 0))) {
+ writel(tx_ring->next_to_use, hw->hw_addr + tx_ring->tdt);
+ /* we need this if more than one processor can write to
+ * our tail at a time, it synchronizes IO on IA64/Altix
+ * systems
+ */
+ mmiowb();
+ }
} else {
dev_kfree_skb_any(skb);
tx_ring->buffer_info[first].time_stamp = 0;
--
1.9.3
^ permalink raw reply related
* [net-next 15/15] net: e1000e: support txtd update delay via xmit_more
From: Jeff Kirsher @ 2015-01-23 2:37 UTC (permalink / raw)
To: davem; +Cc: Florian Westphal, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1421980631-1955-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Florian Westphal <fw@strlen.de>
Don't update Tx tail descriptor if queue hasn't been stopped
and we know at least one more skb will be sent right away.
Signed-off-by: Florian Westphal <fw@strlen.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index aa39a81..1e8c40f 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5444,16 +5444,6 @@ static void e1000_tx_queue(struct e1000_ring *tx_ring, int tx_flags, int count)
wmb();
tx_ring->next_to_use = i;
-
- if (adapter->flags2 & FLAG2_PCIM2PCI_ARBITER_WA)
- e1000e_update_tdt_wa(tx_ring, i);
- else
- writel(i, tx_ring->tail);
-
- /* we need this if more than one processor can write to our tail
- * at a time, it synchronizes IO on IA64/Altix systems
- */
- mmiowb();
}
#define MINIMUM_DHCP_PACKET_SIZE 282
@@ -5655,6 +5645,21 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
(MAX_SKB_FRAGS *
DIV_ROUND_UP(PAGE_SIZE,
adapter->tx_fifo_limit) + 2));
+
+ if (!skb->xmit_more ||
+ netif_xmit_stopped(netdev_get_tx_queue(netdev, 0))) {
+ if (adapter->flags2 & FLAG2_PCIM2PCI_ARBITER_WA)
+ e1000e_update_tdt_wa(tx_ring,
+ tx_ring->next_to_use);
+ else
+ writel(tx_ring->next_to_use, tx_ring->tail);
+
+ /* we need this if more than one processor can write
+ * to our tail at a time, it synchronizes IO on
+ *IA64/Altix systems
+ */
+ mmiowb();
+ }
} else {
dev_kfree_skb_any(skb);
tx_ring->buffer_info[first].time_stamp = 0;
--
1.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM & NET: add fixed phy support on stmmac
From: Ming Lei @ 2015-01-23 2:41 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller; +Cc: linux-samsung-soc, Kukjin Kim, netdev
The EXYNOS5440 sd5v1(arch/arm/boot/dts/exynos5440-sd5v1.dts) has
one stmmc gmac which uses fixed phy, so add fixed phy support for
both EXYNOS5440 and stmmac.
Thanks,
Ming Lei
^ permalink raw reply
* [PATCH 1/2] ARM: EXYNOS: add fixed phy support for EXYNOS5440
From: Ming Lei @ 2015-01-23 2:41 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Kukjin Kim, netdev, Byungho An, Ike Panhc,
Ming Lei
In-Reply-To: <1421980893-14475-1-git-send-email-ming.lei@canonical.com>
From: Byungho An <bh74.an@samsung.com>
This patch adds fixed phy codes for Exynos5440.
This patch can support fixed_phy.
Signed-off-by: Byungho An <bh74.an@samsung.com>
Signed-off-by: Ike Panhc <ike.pan@canonical.com>
Signed-off-by: Ming Lei <ming.lei@canoncial.com>
---
arch/arm/mach-exynos/exynos.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 78eca99b..dfd5699 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -20,6 +20,8 @@
#include <linux/platform_device.h>
#include <linux/pm_domain.h>
#include <linux/irqchip.h>
+#include <linux/phy.h>
+#include <linux/phy_fixed.h>
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
@@ -202,8 +204,21 @@ static void __init exynos_init_irq(void)
exynos_map_pmu();
}
+static struct fixed_phy_status fixed_phy_status __initdata = {
+ .link = 1,
+ .speed = 1000,
+ .duplex = 1,
+};
+
static void __init exynos_dt_machine_init(void)
{
+ struct device_node *gmac_np;
+ unsigned int tmp;
+
+ /* add fixed phy in need */
+ gmac_np = of_find_compatible_node(NULL, NULL, "snps,dwmac-3.70a");
+ if (of_find_property(gmac_np, "fixed_phy", NULL))
+ tmp = fixed_phy_add(PHY_POLL, 1, &fixed_phy_status);
/*
* This is called from smp_prepare_cpus if we've built for SMP, but
* we still need to set it up for PM and firmware ops if not.
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] net: stmmac: add fixed_phy and phy_addr support using DT file
From: Ming Lei @ 2015-01-23 2:41 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Kukjin Kim, netdev, Byungho An, Ming Lei
In-Reply-To: <1421980893-14475-1-git-send-email-ming.lei@canonical.com>
From: Byungho An <bh74.an@samsung.com>
This patch adds codes for DT file support, fixed_phy and phy_addr
can be set in DT file.
Signed-off-by: Byungho An <bh74.an@samsung.com>
(bypass check for fixed phy)
Signed-off-by: Ming Lei<ming.lei@canonical.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++++-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8c6b7c16..ddb4351 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -847,8 +847,11 @@ static int stmmac_init_phy(struct net_device *dev)
* 0 rather than 0xffff. Catch this here and treat 0 as a non-existent
* device as well.
* Note: phydev->phy_id is the result of reading the UID PHY registers.
+ * But phy_id returned from fixed phy is always zero, so bypass the
+ * check for fixed phy.
*/
- if (phydev->phy_id == 0) {
+ if (phydev->phy_id == 0 && (!priv->plat->phy_bus_name ||
+ strcmp(priv->plat->phy_bus_name,"fixed"))) {
phy_disconnect(phydev);
return -ENODEV;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 879e29f..4f11491 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -128,6 +128,7 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
struct device_node *np = pdev->dev.of_node;
struct stmmac_dma_cfg *dma_cfg;
const struct of_device_id *device;
+ u32 phy_addr;
if (!np)
return -ENODEV;
@@ -217,6 +218,12 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
plat->pmt = 1;
}
+ if (of_find_property(np, "fixed_phy", NULL)) {
+ plat->phy_bus_name = "fixed";
+ of_property_read_u32(np, "phy_addr", &phy_addr);
+ plat->phy_addr = phy_addr;
+ }
+
if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
of_device_is_compatible(np, "snps,dwmac-3.710")) {
plat->enh_desc = 1;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] ethernet: fm10k: Actually drop 4 bits
From: Jeff Kirsher @ 2015-01-23 3:27 UTC (permalink / raw)
To: Rasmus Villemoes; +Cc: Alexander Duyck, e1000-devel, netdev, linux-kernel
In-Reply-To: <1421967198-16667-1-git-send-email-linux@rasmusvillemoes.dk>
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
On Thu, 2015-01-22 at 23:53 +0100, Rasmus Villemoes wrote:
> The comment explains the intention, but vid has type u16. Before the
> inner shift, it is promoted to int, which has plenty of space for all
> vid's bits, so nothing is dropped. Use a simple mask instead.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks Rasmus, I will add your patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ARM: EXYNOS: add fixed phy support for EXYNOS5440
From: Florian Fainelli @ 2015-01-23 4:12 UTC (permalink / raw)
To: Ming Lei, linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Ike Panhc, netdev, Ming Lei, Kukjin Kim,
Byungho An
In-Reply-To: <1421980893-14475-2-git-send-email-ming.lei@canonical.com>
Le 22/01/2015 18:41, Ming Lei a écrit :
> From: Byungho An <bh74.an@samsung.com>
>
> This patch adds fixed phy codes for Exynos5440. This patch can
> support fixed_phy.
>
> Signed-off-by: Byungho An <bh74.an@samsung.com> Signed-off-by: Ike
> Panhc <ike.pan@canonical.com> Signed-off-by: Ming Lei
> <ming.lei@canoncial.com> --- arch/arm/mach-exynos/exynos.c | 15
> +++++++++++++++ 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/exynos.c
> b/arch/arm/mach-exynos/exynos.c index 78eca99b..dfd5699 100644 ---
> a/arch/arm/mach-exynos/exynos.c +++
> b/arch/arm/mach-exynos/exynos.c @@ -20,6 +20,8 @@ #include
> <linux/platform_device.h> #include <linux/pm_domain.h> #include
> <linux/irqchip.h> +#include <linux/phy.h> +#include
> <linux/phy_fixed.h>
>
> #include <asm/cacheflush.h> #include <asm/hardware/cache-l2x0.h> @@
> -202,8 +204,21 @@ static void __init exynos_init_irq(void)
> exynos_map_pmu(); }
>
> +static struct fixed_phy_status fixed_phy_status __initdata = { +
> .link = 1, + .speed = 1000, +
> .duplex = 1, +}; + static void __init
> exynos_dt_machine_init(void) { + struct device_node *gmac_np; +
> unsigned int tmp; + + /* add fixed phy in need */ + gmac_np =
> of_find_compatible_node(NULL, NULL, "snps,dwmac-3.70a"); + if
> (of_find_property(gmac_np, "fixed_phy", NULL)) + tmp =
> fixed_phy_add(PHY_POLL, 1, &fixed_phy_status);
Is there a particular reason you are doing this and not using
of_phy_is_fixed_link() and of_phy_register_fixed_link()?
See the gianfar and bcmsysport for examples on how to use it in a
driver along with the relevant Device Tree binding in
Documentation/devicetree/bindings/net/fixed-link.txt for examples.
> /* * This is called from smp_prepare_cpus if we've built for SMP,
> but * we still need to set it up for PM and firmware ops if not.
>
--
Florian
^ permalink raw reply
* Re: [PATCH 2/2] net: stmmac: add fixed_phy and phy_addr support using DT file
From: Florian Fainelli @ 2015-01-23 4:15 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: netdev, linux-samsung-soc, Byungho An, Kukjin Kim
In-Reply-To: <1421980893-14475-3-git-send-email-ming.lei@canonical.com>
Le 22/01/2015 18:41, Ming Lei a écrit :
> From: Byungho An <bh74.an@samsung.com>
>
> This patch adds codes for DT file support, fixed_phy and phy_addr
> can be set in DT file.
>
> Signed-off-by: Byungho An <bh74.an@samsung.com> (bypass check for
> fixed phy) Signed-off-by: Ming Lei<ming.lei@canonical.com> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++++-
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++++++ 2
> files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index
> 8c6b7c16..ddb4351 100644 ---
> a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -847,8
> +847,11 @@ static int stmmac_init_phy(struct net_device *dev) * 0
> rather than 0xffff. Catch this here and treat 0 as a non-existent *
> device as well. * Note: phydev->phy_id is the result of reading the
> UID PHY registers. + * But phy_id returned from fixed phy is
> always zero, so bypass the + * check for fixed phy. */ - if
> (phydev->phy_id == 0) { + if (phydev->phy_id == 0 &&
> (!priv->plat->phy_bus_name || +
> strcmp(priv->plat->phy_bus_name,"fixed"))) {
> phy_disconnect(phydev); return -ENODEV; } diff --git
> a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index
> 879e29f..4f11491 100644 ---
> a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -128,6
> +128,7 @@ static int stmmac_probe_config_dt(struct platform_device
> *pdev, struct device_node *np = pdev->dev.of_node; struct
> stmmac_dma_cfg *dma_cfg; const struct of_device_id *device; + u32
> phy_addr;
>
> if (!np) return -ENODEV; @@ -217,6 +218,12 @@ static int
> stmmac_probe_config_dt(struct platform_device *pdev, plat->pmt =
> 1; }
>
> + if (of_find_property(np, "fixed_phy", NULL)) { +
> plat->phy_bus_name = "fixed"; + of_property_read_u32(np,
> "phy_addr", &phy_addr); + plat->phy_addr = phy_addr; + }
Humm, same here, it would look like you could use the existing Device
Tree helpers for parsing and registering a fixed PHY here, provided
that you use the proper binding though.
BTW, Ming Lei's email is bouncing, do we have an updated email he
could be contacted with?
> + if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
> of_device_is_compatible(np, "snps,dwmac-3.710")) { plat->enh_desc =
> 1;
>
--
Florian
^ permalink raw reply
* [PATCH net-next v3 0/5] switchdev offload flags
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch series introduces new offload flags for switchdev.
Kernel network subsystems can use this flag to accelerate
kernel network functions by offloading to hw.
I expect that there will be need for subsystem specific feature
flag in the future.
This patch series currently only addresses bridge driver link
attribute offloads to hardware.
Looking at the current state of bridge l2 offload in the kernel,
- flag 'self' is the way to directly manage the bridge device in hw via
the ndo_bridge_setlink/ndo_bridge_getlink calls
- flag 'master' is always used to manage the in kernel bridge devices
via the same ndo_bridge_setlink/ndo_bridge_getlink calls
Today these are used separately. The nic offloads use hwmode "vepa/veb" to go
directly to hw with the "self" flag.
At this point i am trying not to introduce any new user facing flags/attributes.
In the model where we want the kernel bridging to be accelerated with
hardware, we very much want the bridge driver to be involved.
In this proposal,
- The offload flag/bit helps switch asic drivers to indicate that they
accelerate the kernel networking objects/functions
- The user does not have to specify a new flag to do so. A bridge created with
switch asic ports will be accelerated if the switch driver supports it.
- The user can continue to directly manage l2 in nics (ixgbe) using the
existing hwmode/self flags
- It also does not stop users from using the 'self' flag to talk to the
switch asic driver directly
- Involving the bridge driver makes sure the add/del notifications to user
space go out after both kernel and hardware are programmed
(To selectively offload bridge port attributes,
example learning in hw only etc, we can introduce offload bits for
per bridge port flag attribute as in my previous patch
https://patchwork.ozlabs.org/patch/413211/. I have not included that in this
series)
v2
- try a different name for the offload flag/bit
- tries to solve the stacked netdev case by traversing the lowerdev
list to reach the switch port
v3 -
- Tested with bond as bridge port for the stacked device case.
Includes a bond_fix_features change to not ignore the
NETIF_F_HW_NETFUNC_OFFLOAD flag
- Some checkpatch fixes
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Roopa Prabhu (5):
netdev: introduce new NETIF_F_HW_NETFUNC_OFFLOAD feature flag for
switch device offloads
swdevice: add new api to set and del bridge port attributes
bridge: offload bridge port attributes to switch asic if feature flag
set
rocker: set feature NETIF_F_HW_NETFUNC_OFFLOAD
bonding: handle NETIF_F_HW_NETFUNC_OFFLOAD flag to bonding feature
mask
drivers/net/bonding/bond_main.c | 6 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
drivers/net/ethernet/rocker/rocker.c | 5 +-
include/linux/netdev_features.h | 6 ++-
include/linux/netdevice.h | 4 +-
include/net/switchdev.h | 17 +++++-
net/bridge/br_netlink.c | 30 +++++++++--
net/bridge/br_private.h | 4 +-
net/core/rtnetlink.c | 10 ++--
net/switchdev/switchdev.c | 70 +++++++++++++++++++++++++
10 files changed, 135 insertions(+), 19 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH net-next v3 1/5] netdev: introduce new NETIF_F_HW_NETFUNC_OFFLOAD feature flag for switch device offloads
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This is a high level feature flag for all switch asic offloads
switch drivers set this flag on switch ports. Logical devices like
bridge, bonds, vxlans can inherit this flag from their slaves/ports.
The patch also adds the flag to NETIF_F_ONE_FOR_ALL, so that it gets
propagated to the upperdevices (bridges and bonds).
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
include/linux/netdev_features.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 8e30685..784a461 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -66,6 +66,7 @@ enum {
NETIF_F_HW_VLAN_STAG_FILTER_BIT,/* Receive filtering on VLAN STAGs */
NETIF_F_HW_L2FW_DOFFLOAD_BIT, /* Allow L2 Forwarding in Hardware */
NETIF_F_BUSY_POLL_BIT, /* Busy poll */
+ NETIF_F_HW_NETFUNC_OFFLOAD_BIT, /* HW switch offload */
/*
* Add your fresh new feature above and remember to update
@@ -124,6 +125,7 @@ enum {
#define NETIF_F_HW_VLAN_STAG_TX __NETIF_F(HW_VLAN_STAG_TX)
#define NETIF_F_HW_L2FW_DOFFLOAD __NETIF_F(HW_L2FW_DOFFLOAD)
#define NETIF_F_BUSY_POLL __NETIF_F(BUSY_POLL)
+#define NETIF_F_HW_NETFUNC_OFFLOAD __NETIF_F(HW_NETFUNC_OFFLOAD)
/* Features valid for ethtool to change */
/* = all defined minus driver/device-class-related */
@@ -159,7 +161,9 @@ enum {
*/
#define NETIF_F_ONE_FOR_ALL (NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ROBUST | \
NETIF_F_SG | NETIF_F_HIGHDMA | \
- NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED)
+ NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED | \
+ NETIF_F_HW_NETFUNC_OFFLOAD)
+
/*
* If one device doesn't support one of these features, then disable it
* for all in netdev_increment_features.
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds two new api's netdev_switch_port_bridge_setlink
and netdev_switch_port_bridge_dellink to offload bridge port attributes
to switch asic
(The names of the apis look odd with 'switch_port_bridge',
but am more inclined to change the prefix of the api to something else.
Will take any suggestions).
The api's look at the NETIF_F_HW_NETFUNC_OFFLOAD feature flag to
pass bridge port attributes to the port device.
If the device has the NETIF_F_HW_NETFUNC_OFFLOAD, but does not support
the bridge port attribute offload ndo, call bridge port attribute ndo's on
the lowerdevs if supported. This is one way to pass bridge port attributes
through stacked netdevs (example when bridge port is a bond and bond slaves
are switch ports).
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
include/net/switchdev.h | 17 ++++++++++-
net/switchdev/switchdev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 8a6d164..362f53a 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -17,7 +17,10 @@
int netdev_switch_parent_id_get(struct net_device *dev,
struct netdev_phys_item_id *psid);
int netdev_switch_port_stp_update(struct net_device *dev, u8 state);
-
+int netdev_switch_port_bridge_setlink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags);
+int netdev_switch_port_bridge_dellink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags);
#else
static inline int netdev_switch_parent_id_get(struct net_device *dev,
@@ -32,6 +35,18 @@ static inline int netdev_switch_port_stp_update(struct net_device *dev,
return -EOPNOTSUPP;
}
+int netdev_switch_port_bridge_setlink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags)
+{
+ return -EOPNOTSUPP;
+}
+
+int netdev_switch_port_bridge_dellink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags)
+{
+ return -EOPNOTSUPP;
+}
+
#endif
#endif /* _LINUX_SWITCHDEV_H_ */
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index d162b21..bf0be98 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -50,3 +50,73 @@ int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
return ops->ndo_switch_port_stp_update(dev, state);
}
EXPORT_SYMBOL(netdev_switch_port_stp_update);
+
+/**
+ * netdev_switch_port_bridge_setlink - Notify switch device port of bridge
+ * port attributes
+ *
+ * @dev: port device
+ * @nlh: netlink msg with bridge port attributes
+ *
+ * Notify switch device port of bridge port attributes
+ */
+int netdev_switch_port_bridge_setlink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags)
+{
+ const struct net_device_ops *ops = dev->netdev_ops;
+ struct net_device *lower_dev;
+ struct list_head *iter;
+ int ret = 0, err = 0;
+
+ if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
+ return err;
+
+ if (ops->ndo_bridge_setlink) {
+ WARN_ON(!ops->ndo_switch_parent_id_get);
+ return ops->ndo_bridge_setlink(dev, nlh, flags);
+ }
+
+ netdev_for_each_lower_dev(dev, lower_dev, iter) {
+ err = netdev_switch_port_bridge_setlink(lower_dev, nlh, flags);
+ if (err)
+ ret = err;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(netdev_switch_port_bridge_setlink);
+
+/**
+ * netdev_switch_port_bridge_dellink - Notify switch device port of bridge
+ * attribute delete
+ *
+ * @dev: port device
+ * @nlh: netlink msg with bridge port attributes
+ *
+ * Notify switch device port of bridge port attribute delete
+ */
+int netdev_switch_port_bridge_dellink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags)
+{
+ const struct net_device_ops *ops = dev->netdev_ops;
+ struct net_device *lower_dev;
+ struct list_head *iter;
+ int ret = 0, err = 0;
+
+ if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
+ return err;
+
+ if (ops->ndo_bridge_dellink) {
+ WARN_ON(!ops->ndo_switch_parent_id_get);
+ return ops->ndo_bridge_dellink(dev, nlh, flags);
+ }
+
+ netdev_for_each_lower_dev(dev, lower_dev, iter) {
+ err = netdev_switch_port_bridge_dellink(lower_dev, nlh, flags);
+ if (err)
+ ret = err;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(netdev_switch_port_bridge_dellink);
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v3 3/5] bridge: offload bridge port attributes to switch asic if feature flag set
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds support to set/del bridge port attributes in hardware from
the bridge driver.
When the user sends a bridge setlink message, it will come in with 'master',
- go to the bridge driver ndo_bridge_setlink handler,
- set settings in the kernel
- if offload mode is set on the port, also call the swicthdev api to
propagate the attrs to the switchdev hardware
If you want to act on the hw alone, you can still use the self flag to
go to the switch hw or switch port driver directly.
With this, it also makes sure a notification goes out only after the
attributes are set both in the kernel and hw.
The patch calls switchdev api only if BRIDGE_FLAGS_SELF is not set.
This is because the offload cases with BRIDGE_FLAGS_SELF are handled in
the caller (in rtnetlink.c). This needed flags (IFLA_BRIDGE_FLAGS) to be
passed to bridge setlink and dellink functions, to avoid
another call to parse of IFLA_AF_SPEC in br_setlink/br_getlink respectively.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
drivers/net/ethernet/rocker/rocker.c | 2 +-
include/linux/netdevice.h | 6 +++--
net/bridge/br_netlink.c | 30 ++++++++++++++++++++-----
net/bridge/br_private.h | 4 ++--
net/core/rtnetlink.c | 10 +++++----
6 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ed2c7d..13425e5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7786,7 +7786,7 @@ static int ixgbe_ndo_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
}
static int ixgbe_ndo_bridge_setlink(struct net_device *dev,
- struct nlmsghdr *nlh)
+ struct nlmsghdr *nlh, u16 flags)
{
struct ixgbe_adapter *adapter = netdev_priv(dev);
struct nlattr *attr, *br_spec;
diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
index 2f398fa..109aa1b 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -3713,7 +3713,7 @@ skip:
}
static int rocker_port_bridge_setlink(struct net_device *dev,
- struct nlmsghdr *nlh)
+ struct nlmsghdr *nlh, u16 flags)
{
struct rocker_port *rocker_port = netdev_priv(dev);
struct nlattr *protinfo;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c31f74d..1c8641f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1151,13 +1151,15 @@ struct net_device_ops {
int idx);
int (*ndo_bridge_setlink)(struct net_device *dev,
- struct nlmsghdr *nlh);
+ struct nlmsghdr *nlh,
+ u16 flags);
int (*ndo_bridge_getlink)(struct sk_buff *skb,
u32 pid, u32 seq,
struct net_device *dev,
u32 filter_mask);
int (*ndo_bridge_dellink)(struct net_device *dev,
- struct nlmsghdr *nlh);
+ struct nlmsghdr *nlh,
+ u16 flags);
int (*ndo_change_carrier)(struct net_device *dev,
bool new_carrier);
int (*ndo_get_phys_port_id)(struct net_device *dev,
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 9f5eb55..f73b094 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -16,6 +16,7 @@
#include <net/rtnetlink.h>
#include <net/net_namespace.h>
#include <net/sock.h>
+#include <net/switchdev.h>
#include <uapi/linux/if_bridge.h>
#include "br_private.h"
@@ -359,13 +360,13 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
}
/* Change state and parameters on port. */
-int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
+int br_setlink(struct net_device *dev, struct nlmsghdr *nlh, u16 flags)
{
struct nlattr *protinfo;
struct nlattr *afspec;
struct net_bridge_port *p;
struct nlattr *tb[IFLA_BRPORT_MAX + 1];
- int err = 0;
+ int err = 0, ret_offload = 0;
protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_PROTINFO);
afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
@@ -407,19 +408,28 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
afspec, RTM_SETLINK);
}
+ if (!(flags & BRIDGE_FLAGS_SELF)) {
+ /* set bridge attributes in hardware if supported
+ */
+ ret_offload = netdev_switch_port_bridge_setlink(dev, nlh,
+ flags);
+ if (ret_offload && ret_offload != -EOPNOTSUPP)
+ br_warn(p->br, "error setting attrs on port %u(%s)\n",
+ (unsigned int)p->port_no, p->dev->name);
+ }
+
if (err == 0)
br_ifinfo_notify(RTM_NEWLINK, p);
-
out:
return err;
}
/* Delete port information */
-int br_dellink(struct net_device *dev, struct nlmsghdr *nlh)
+int br_dellink(struct net_device *dev, struct nlmsghdr *nlh, u16 flags)
{
struct nlattr *afspec;
struct net_bridge_port *p;
- int err;
+ int err = 0, ret_offload = 0;
afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
if (!afspec)
@@ -433,6 +443,16 @@ int br_dellink(struct net_device *dev, struct nlmsghdr *nlh)
err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
afspec, RTM_DELLINK);
+ if (!(flags & BRIDGE_FLAGS_SELF)) {
+ /* del bridge attributes in hardware
+ */
+ ret_offload = netdev_switch_port_bridge_dellink(dev, nlh,
+ flags);
+ if (ret_offload && ret_offload != -EOPNOTSUPP)
+ br_warn(p->br, "error deleting attrs on port %u (%s)\n",
+ (unsigned int)p->port_no, p->dev->name);
+ }
+
return err;
}
static int br_validate(struct nlattr *tb[], struct nlattr *data[])
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index aea3d13..0ebad7c 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -815,8 +815,8 @@ extern struct rtnl_link_ops br_link_ops;
int br_netlink_init(void);
void br_netlink_fini(void);
void br_ifinfo_notify(int event, struct net_bridge_port *port);
-int br_setlink(struct net_device *dev, struct nlmsghdr *nlmsg);
-int br_dellink(struct net_device *dev, struct nlmsghdr *nlmsg);
+int br_setlink(struct net_device *dev, struct nlmsghdr *nlmsg, u16 flags);
+int br_dellink(struct net_device *dev, struct nlmsghdr *nlmsg, u16 flags);
int br_getlink(struct sk_buff *skb, u32 pid, u32 seq, struct net_device *dev,
u32 filter_mask);
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d06107d..70e5c93 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2946,7 +2946,7 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh)
goto out;
}
- err = br_dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
+ err = br_dev->netdev_ops->ndo_bridge_setlink(dev, nlh, flags);
if (err)
goto out;
@@ -2957,7 +2957,8 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh)
if (!dev->netdev_ops->ndo_bridge_setlink)
err = -EOPNOTSUPP;
else
- err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
+ err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh,
+ flags);
if (!err)
flags &= ~BRIDGE_FLAGS_SELF;
@@ -3019,7 +3020,7 @@ static int rtnl_bridge_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
goto out;
}
- err = br_dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
+ err = br_dev->netdev_ops->ndo_bridge_dellink(dev, nlh, flags);
if (err)
goto out;
@@ -3030,7 +3031,8 @@ static int rtnl_bridge_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
if (!dev->netdev_ops->ndo_bridge_dellink)
err = -EOPNOTSUPP;
else
- err = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
+ err = dev->netdev_ops->ndo_bridge_dellink(dev, nlh,
+ flags);
if (!err)
flags &= ~BRIDGE_FLAGS_SELF;
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v3 4/5] rocker: set feature NETIF_F_HW_NETFUNC_OFFLOAD
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch sets the NETIF_F_HW_NETFUNC_OFFLOAD feature flag on rocker ports
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/ethernet/rocker/rocker.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
index 109aa1b..3aa0e85 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -4004,7 +4004,8 @@ static int rocker_probe_port(struct rocker *rocker, unsigned int port_number)
NAPI_POLL_WEIGHT);
rocker_carrier_init(rocker_port);
- dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
+ dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER |
+ NETIF_F_HW_NETFUNC_OFFLOAD;
err = register_netdev(dev);
if (err) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v3 5/5] bonding: handle NETIF_F_HW_NETFUNC_OFFLOAD flag to bonding feature mask
From: roopa @ 2015-01-23 4:33 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
vyasevic, ronen.arad
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
We want bond to pick up the offload flag if any of its slaves have it.
NETIF_F_HW_NETFUNC_OFFLOAD flag is added to the mask, so that
netdev_increment_features does not ignore it.
If this needs to be under CONFIG_NET_SWITCHDEV, I can do so.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/bonding/bond_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 184c434..4304194 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -979,7 +979,11 @@ static netdev_features_t bond_fix_features(struct net_device *dev,
netdev_features_t mask;
struct slave *slave;
- mask = features;
+ /* If any slave has the offload feature flag set,
+ * set the offload flag on the bond.
+ */
+ mask = features | NETIF_F_HW_NETFUNC_OFFLOAD;
+
features &= ~NETIF_F_ONE_FOR_ALL;
features |= NETIF_F_ALL_FOR_ALL;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: stmmac: add fixed_phy and phy_addr support using DT file
From: Ming Lei @ 2015-01-23 4:57 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel, David S. Miller, Network Development,
linux-samsung-soc, Byungho An, Kukjin Kim
In-Reply-To: <54C1CADD.4060103@gmail.com>
On Fri, Jan 23, 2015 at 12:15 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 22/01/2015 18:41, Ming Lei a écrit :
>> From: Byungho An <bh74.an@samsung.com>
>>
>> This patch adds codes for DT file support, fixed_phy and phy_addr
>> can be set in DT file.
>>
>> Signed-off-by: Byungho An <bh74.an@samsung.com> (bypass check for
>> fixed phy) Signed-off-by: Ming Lei<ming.lei@canonical.com> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++++-
>> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++++++ 2
>> files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index
>> 8c6b7c16..ddb4351 100644 ---
>> a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -847,8
>> +847,11 @@ static int stmmac_init_phy(struct net_device *dev) * 0
>> rather than 0xffff. Catch this here and treat 0 as a non-existent *
>> device as well. * Note: phydev->phy_id is the result of reading the
>> UID PHY registers. + * But phy_id returned from fixed phy is
>> always zero, so bypass the + * check for fixed phy. */ - if
>> (phydev->phy_id == 0) { + if (phydev->phy_id == 0 &&
>> (!priv->plat->phy_bus_name || +
>> strcmp(priv->plat->phy_bus_name,"fixed"))) {
>> phy_disconnect(phydev); return -ENODEV; } diff --git
>> a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index
>> 879e29f..4f11491 100644 ---
>> a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -128,6
>> +128,7 @@ static int stmmac_probe_config_dt(struct platform_device
>> *pdev, struct device_node *np = pdev->dev.of_node; struct
>> stmmac_dma_cfg *dma_cfg; const struct of_device_id *device; + u32
>> phy_addr;
>>
>> if (!np) return -ENODEV; @@ -217,6 +218,12 @@ static int
>> stmmac_probe_config_dt(struct platform_device *pdev, plat->pmt =
>> 1; }
>>
>> + if (of_find_property(np, "fixed_phy", NULL)) { +
>> plat->phy_bus_name = "fixed"; + of_property_read_u32(np,
>> "phy_addr", &phy_addr); + plat->phy_addr = phy_addr; + }
>
> Humm, same here, it would look like you could use the existing Device
> Tree helpers for parsing and registering a fixed PHY here, provided
> that you use the proper binding though.
OK, I will try to use the existing DT helpers in v1.
>
> BTW, Ming Lei's email is bouncing, do we have an updated email he
> could be contacted with?
Sorry, my signed-off-by email in the 1st patch is wrong(typo), and
the address in this email and patch is correct.
Thanks,
Ming Lei
^ permalink raw reply
* rxhash for virtio_net
From: Nick H @ 2015-01-23 5:43 UTC (permalink / raw)
To: netdev; +Cc: mst, jasonwang
While trying to enable rxhash for virtio_net over net-next, I found
that we still do not support it. Quick Google search yields several
patches (including flow-director for virtio_net), but looks like none
of them made it in. If my observation is correct, what are the
prominent reasons why rxhash support for virtio has not made its way
in ? (I see some concerns over Out-of-order delivery etc, any other ?
). Without rxhash for virtio, is there a way to tie a flow to a
particular cpu on host and guest side ?
Thanks,
N
^ permalink raw reply
* Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
From: Ahmed S. Darwish @ 2015-01-23 6:07 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Andri Yngvason, Olivier Sobrie, Oliver Hartkopp,
Marc Kleine-Budde, Linux-CAN, netdev, LKML
In-Reply-To: <49707d45a389a1acb9ccec4295d05762@grandegger.com>
On Wed, Jan 21, 2015 at 05:13:45PM +0100, Wolfgang Grandegger wrote:
> On Wed, 21 Jan 2015 10:36:47 -0500, "Ahmed S. Darwish"
> <darwish.07@gmail.com> wrote:
> > On Wed, Jan 21, 2015 at 03:00:15PM +0000, Andri Yngvason wrote:
> >> Quoting Ahmed S. Darwish (2015-01-21 14:43:23)
> >> > Hi!
> >
> > ...
> >
> >> > <-- Unplug the cable -->
> >> >
> >> > (000.009106) can0 20000080 [8] 00 00 00 00 00 00 08 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{8}{0}}
> >> > (000.001872) can0 20000080 [8] 00 00 00 00 00 00 10 00
>
> For a bus-errors I would also expcect some more information in the
> data[2..3] fields. But these are always zero.
>
M16C error factors made it possible to report things like
CAN_ERR_PROT_FORM/STUFF/BIT0/BIT1/TX in data[2], and
CAN_ERR_PROT_LOC_ACK/CRC_DEL in data[3].
Unfortunately such error factors are only reported in Leaf, but
not in USBCan-II due to the wire format change in the error event:
struct leaf_msg_error_event {
u8 tid;
u8 flags;
__le16 time[3];
u8 channel;
u8 padding;
u8 tx_errors_count;
u8 rx_errors_count;
u8 status;
u8 error_factor;
} __packed;
struct usbcan_msg_error_event {
u8 tid;
u8 padding;
u8 tx_errors_count_ch0;
u8 rx_errors_count_ch0;
u8 tx_errors_count_ch1;
u8 rx_errors_count_ch1;
u8 status_ch0;
u8 status_ch1;
__le16 time;
} __packed;
I speculate that the wire format was changed due to controller
bugs in the USBCan-II, which was slightly mentioned in their
data sheets here:
http://www.kvaser.com/canlib-webhelp/page_hardware_specific_can_controllers.html
So it seems there's really no way for filling such bus error
info given the very limited amount of data exported :-(
The issue of incomplete data does not even stop here, kindly
check below notes regarding reverse state transitions:
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{16}{0}}
> >> [...]
> >> > error-counter-tx-rx{{80}{0}}
> >> > (000.001910) can0 20000080 [8] 00 00 00 00 00 00 58 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{88}{0}}
> >> > (000.001753) can0 20000084 [8] 00 08 00 00 00 00 60 00
> >> > ERRORFRAME
> >> > controller-problem{tx-error-warning}
> >> Good.
> >> > bus-error
> >> > error-counter-tx-rx{{96}{0}}
> >
> > Nice.
> >
> >> > (000.001720) can0 20000080 [8] 00 00 00 00 00 00 68 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{104}{0}}
> >> > (000.001876) can0 20000080 [8] 00 00 00 00 00 00 70 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{112}{0}}
> >> > (000.001749) can0 20000080 [8] 00 00 00 00 00 00 78 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{120}{0}}
> >> > (000.001771) can0 20000084 [8] 00 20 00 00 00 00 80 00
> >> > ERRORFRAME
> >> > controller-problem{tx-error-passive}
> >> Also good.
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >
> > Also nice :-)
> >
> >> > (000.001868) can0 20000080 [8] 00 00 00 00 00 00 80 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >> > (000.001982) can0 20000080 [8] 00 00 00 00 00 00 80 00
> >> > ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >> >
> >> > (( Then a continous flood, exactly similar to the above packet,
> >> > appears.
> >> > Unfortunately this flooding is a firmware problem. ))
> >> >
> >> > <-- Replug the cable, after a good amount of time -->
> >> >
> >> Where are the reverse state transitions?
> >> >
> >
> > Hmmm...
> >
> > [ ... ]
> >>
> >> Reverse state transitions are missing from the logs. See comments
> above.
> >>
> >
> > When the device is on the _receiving_ end, and I unplug the CAN cable
> after
> > introducing some noise to the level of reaching WARNING or PASSIVE, I
> > receive a BUS_ERROR event with the rxerr count reset back to 0 or 1. In
> > that case, the driver correctly transitions back the state to
> ERROR_ACTIVE
> > and candump produces something similar to:
> >
> > (000.000362) can0 2000008C [8] 00 40 40 00 00 00 00 01
> > ERRORFRAME
> > controller-problem{}
> > protocol-violation{{back-to-error-active}{}}
> > bus-error
> > error-counter-tx-rx{{0}{1}}
> >
> > which is, AFAIK, the correct behaviour from the driver side.
> >
> > Meanwhile, when the device is on the _sending_ end and I re-plug the CAN
> > cable again. Sometimes I receive events with txerr reset to 0 or 1, and
> > the driver correctly reverts back to ERROR_ACTIVE in that case. But on
> > another times like the quoted case above, I don't receive any events
> > resetting txerr back -- only data packets on the bus.
>
> Well, the firmware seems to report *only* bus-errors via
> CMD_CAN_ERROR_EVENT messages, also carrying the new state, but no
> CMD_CHIP_STATE_EVENT just for the state changes.
>
I've dumped _every_ message I receive from the firmware while
disconnecting the CAN bus, waiting a while, and connecting it again.
I really received _nothing_ from the firmware when the CAN bus was
reconnected and the data packets were flowing again. Not even a
single CHIP_STATE_EVENT, even after waiting for a long time.
So it's basically:
...
ERR EVENT, txerr=128, rxerr=0
ERR EVENT, txerr=128, rxerr=0
ERR EVENT, txerr=128, rxerr=0
...
then complete silence, except the data frames. I've even tried with
different versions of the firmware, but the same behaviour persisted.
> > So, What can the driver do given the above?
>
> Little if the notification does not come.
>
We can poll the state by sending CMD_GET_CHIP_STATE to the firmware,
and it will hopefully reply with a CHIP_STATE_EVENT response
containing the new txerr and rxerr values that we can use for
reverse state transitions.
But do we _really_ want to go through the path? I feel that it will
open some cans of worms w.r.t. concurrent access to both the netdev
and USB stacks from a single driver.
A possible solution can be setting up a kernel thread that queries
for a CHIP_STATE_EVENT every second?
Your inputs on this is appreciated.
> Wolfgang.
>
Regards,
Darwish
^ permalink raw reply
* [PATCH net-next v2] iproute2: bridge: support vlan range
From: roopa @ 2015-01-23 6:25 UTC (permalink / raw)
To: davem, stephen, netdev, vyasevic; +Cc: wkok, sfeldma
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds vlan range support to bridge command
using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
BRIDGE_VLAN_INFO_RANGE_END.
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
$bridge vlan add vid 10-15 dev dummy0
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
10
11
12
13
14
15
$bridge vlan del vid 14 dev dummy0
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
10
11
12
13
15
$bridge vlan del vid 10-15 dev dummy0
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
v2: fix vid check
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
---
bridge/vlan.c | 44 ++++++++++++++++++++++++++++++++++++++++----
include/linux/if_bridge.h | 2 ++
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/bridge/vlan.c b/bridge/vlan.c
index 3bd7b0d..88992e6 100644
--- a/bridge/vlan.c
+++ b/bridge/vlan.c
@@ -32,6 +32,7 @@ static int vlan_modify(int cmd, int argc, char **argv)
} req;
char *d = NULL;
short vid = -1;
+ short vid_end = -1;
struct rtattr *afspec;
struct bridge_vlan_info vinfo;
unsigned short flags = 0;
@@ -49,8 +50,18 @@ static int vlan_modify(int cmd, int argc, char **argv)
NEXT_ARG();
d = *argv;
} else if (strcmp(*argv, "vid") == 0) {
+ char *p;
NEXT_ARG();
- vid = atoi(*argv);
+ p = strchr(*argv, '-');
+ if (p) {
+ *p = '\0';
+ p++;
+ vid = atoi(*argv);
+ vid_end = atoi(p);
+ vinfo.flags |= BRIDGE_VLAN_INFO_RANGE_BEGIN;
+ } else {
+ vid = atoi(*argv);
+ }
} else if (strcmp(*argv, "self") == 0) {
flags |= BRIDGE_FLAGS_SELF;
} else if (strcmp(*argv, "master") == 0) {
@@ -83,15 +94,40 @@ static int vlan_modify(int cmd, int argc, char **argv)
return -1;
}
- vinfo.vid = vid;
+ if (vinfo.flags & BRIDGE_VLAN_INFO_RANGE_BEGIN) {
+ if (vid_end == -1 || vid_end >= 4096 || vid >= vid_end) {
+ fprintf(stderr, "Invalid VLAN range \"%hu-%hu\"\n",
+ vid, vid_end);
+ return -1;
+ }
+ if (vinfo.flags & BRIDGE_VLAN_INFO_PVID) {
+ fprintf(stderr,
+ "pvid cannot be configured for a vlan range\n");
+ return -1;
+ }
+ }
afspec = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
if (flags)
addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
- addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
- sizeof(vinfo));
+ vinfo.vid = vid;
+ if (vid_end != -1) {
+ /* send vlan range start */
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ vinfo.flags &= ~BRIDGE_VLAN_INFO_RANGE_BEGIN;
+
+ /* Now send the vlan range end */
+ vinfo.flags |= BRIDGE_VLAN_INFO_RANGE_END;
+ vinfo.vid = vid_end;
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ } else {
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ }
addattr_nest_end(&req.n, afspec);
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 19ff22a..efa10b8 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -125,6 +125,8 @@ enum {
#define BRIDGE_VLAN_INFO_MASTER (1<<0) /* Operate on Bridge device as well */
#define BRIDGE_VLAN_INFO_PVID (1<<1) /* VLAN is PVID, ingress untagged */
#define BRIDGE_VLAN_INFO_UNTAGGED (1<<2) /* VLAN egresses untagged */
+#define BRIDGE_VLAN_INFO_RANGE_BEGIN (1<<3) /* VLAN is start of vlan range */
+#define BRIDGE_VLAN_INFO_RANGE_END (1<<4) /* VLAN is end of vlan range */
struct bridge_vlan_info {
__u16 flags;
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Stephen Hemminger @ 2015-01-23 6:40 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, hannes
In-Reply-To: <1421263039-96198-1-git-send-email-dsahern@gmail.com>
On Wed, 14 Jan 2015 12:17:19 -0700
David Ahern <dsahern@gmail.com> wrote:
> Currently, ipv6 addresses are flushed when the interface is configured down:
>
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>
> Add a new sysctl to make this behavior optional. Setting defaults to flush
> addresses to maintain backwards compatibility. When reset flushing is bypassed:
>
> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::4:11ff:fe22:3301/64 scope link
> valid_lft forever preferred_lft forever
>
> Suggested-by: Hannes Frederic Sowa <hannes@redhat.com>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> Cc: Hannes Frederic Sowa <hannes@redhat.com>
Would this break existing application expecting a particular semantic
by listening to netlink? What happens to packets received with the static
address when interface is down? With IPv4 Linux is mostly a weak host
model, and IPv6 somewhere in between.
For vendors that control the application stack or have limited number
of services this would work fine, but what about RHEL?
^ permalink raw reply
* Re: [PATCH net-next 1/2] tipc: fix excessive network event logging
From: Erik Hugne @ 2015-01-23 6:44 UTC (permalink / raw)
To: Joe Perches; +Cc: richard.alpe, netdev, jon.maloy, ying.xue, tipc-discussion
In-Reply-To: <1421947487.2702.1.camel@perches.com>
On Thu, Jan 22, 2015 at 09:24:47AM -0800, Joe Perches wrote:
> On Thu, 2015-01-22 at 17:10 +0100, erik.hugne@ericsson.com wrote:
> > From: Erik Hugne <erik.hugne@ericsson.com>
> >
> > If a large number of namespaces is spawned on a node and TIPC is
> > enabled in each of these, the excessive printk tracing of network
> > events will cause the system to grind down to a near halt.
> > The traces are still of debug value, so instead of removing them
> > completely we fix it by changing the link state and node availability
> > logging debug traces.
>
> Maybe some of these should be net_<level>_ratelimited(fmt, ...)
We proposed that initially, but changed all to pr_debug after David's comment:
http://www.spinics.net/lists/netdev/msg312902.html
The topology information (links going up/down) can be accessed
both via netlink ('tipc link list' command) and the topology server
via a subscription API.
//E
^ permalink raw reply
* Re: [PATCH net-next v2] iproute2: bridge: support vlan range
From: Stephen Hemminger @ 2015-01-23 6:51 UTC (permalink / raw)
To: roopa; +Cc: davem, netdev, vyasevic, wkok, sfeldma
In-Reply-To: <1421994310-48811-1-git-send-email-roopa@cumulusnetworks.com>
On Thu, 22 Jan 2015 22:25:10 -0800
roopa@cumulusnetworks.com wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch adds vlan range support to bridge command
> using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
> BRIDGE_VLAN_INFO_RANGE_END.
>
> $bridge vlan show
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
>
> $bridge vlan add vid 10-15 dev dummy0
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
> 10
> 11
> 12
> 13
> 14
> 15
Doing on vlan id per line gets ridiculous with 1000 vlan's
how about something more compact?
^ permalink raw reply
* Re: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
From: Alexander Duyck @ 2015-01-23 7:18 UTC (permalink / raw)
To: Hiroshi Shimamoto, Skidmore, Donald C, Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, David Laight,
Hayato Momma
In-Reply-To: <7F861DC0615E0C47A872E6F3C5FCDDBD05E0B6B1@BPXM14GP.gisp.nec.co.jp>
On 01/22/2015 04:32 PM, Hiroshi Shimamoto wrote:
>> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
>>> "Skidmore, Donald C" <donald.c.skidmore@intel.com> writes:
>>>
>>>> My hang up is more related to: without the nob to enable it (off by
>>>> default) we are letting one VF dictate policy for all the other VFs
>>>> and the PF. If one VF needs to be in promiscuous multicast so is
>>>> everyone else. Their stacks now needs to deal with all the extra
>>>> multicast packets. As you point out this might not be a direct
>>>> concern for isolation in that the VM could have 'chosen' to join any
>>>> Multicast group and seen this traffic. My concern over isolation is
>>>> one VF has chosen that all the other VM now have to see this multicast
>>>> traffic.
>>> Apologies if this question is stupid, but I just have to ask about stuff I don't
>>> understand...
>>>
>>> Looking at the proposed implementation, the promiscous multicast flag
>>> seems to be a per-VF flag:
>>>
>>> +int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf, bool
>>> +setting) {
>>> + struct ixgbe_adapter *adapter = netdev_priv(netdev);
>>> + struct ixgbe_hw *hw = &adapter->hw;
>>> + u32 vmolr;
>>> +
>>> + if (vf >= adapter->num_vfs)
>>> + return -EINVAL;
>>> +
>>> + adapter->vfinfo[vf].mc_promisc_enabled = setting;
>>> +
>>> + vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
>>> + if (setting) {
>>> + e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
>>> + vmolr |= IXGBE_VMOLR_MPE;
>>> + } else {
>>> + e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
>>> + vmolr &= ~IXGBE_VMOLR_MPE;
>>> + }
>>> +
>>> + IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
>>> +
>>> + return 0;
>>> +}
>>> +
>>>
>>> I haven't read the data sheet, but I took a quick look at the excellent high
>>> level driver docs:
>>> http://www.intel.com/content/dam/doc/design-guide/82599-sr-iov-driver-
>>> companion-guide.pdf
>>>
>>> It mentions "Multicast Promiscuous Enable" in its "Thoughts for
>>> Customization" section:
>>>
>>> 7.1 Multicast Promiscuous Enable
>>>
>>> The controller has provisions to allow each VF to be put into Multicast
>>> Promiscuous mode. The Intel reference driver does not configure this
>>> option .
>>>
>>> The capability can be enabled/disabled by manipulating the MPE field (bit
>>> 28) of the PF VF L2 Control Register (PFVML2FLT – 0x0F000)
>>>
>>> and showing a section from the data sheet describing the "PF VM L2 Control
>>> Register - PFVML2FLT[n] (0x0F000 + 4 * n, n=0...63; RW)"
>>>
>>> To me it looks like enabling Promiscuos Multicast for a VF won't affect any
>>> other VF at all. Is this really not the case?
>>>
>>>
>>>
>>> Bjørn
>> Clearly not a dumb question at all and I'm glad you mentioned that. :) I was going off the assumption, been awhile since
>> I read the patch, that the patch was using FCTRL.MPE or MANC.MCST_PASS_L2 which would turn multicast promiscuous on for
>> everyone. Since the patch is using PFVML2FLT.MPE this lessens my concern over effect on the entire system.
> I believe the patches for this VF multicast promiscuous mode is per VF.
>
>> That said I still would prefer having a way to override this behavior on the PF, although I admit my argument is weaker.
>> I'm still concerned about a VF changing the behavior of the PF without any way to prevent it. This might be one part
>> philosophical (PF sets policy not the VF) but this still could have a noticeable effect on the overall system. If any
>> other VFs (or the PF) are receiving MC packets these will have to be replicated which will be a performance hit. When
>> we use the MC hash this is limited vs. when anyone is in MC promiscuous every MC packet used by another pool would be
>> replicated. I could imagine in some environments (i.e. public clouds) where you don't trust what is running in your VM
>> you might what to block this from happening.
> I understand your request and I'm thinking to submit the patches
> 1) Add new mbox API between ixgbe/ixgbevf to turn MC promiscuous on,
> and enables it when ixgbevf needs over 30 MC addresses.
> 2) Add a policy knob to prevent enabling it from the PF.
>
> Does it seem okay?
I would advise that if such a knob is added it should be set to disabled
by default. The main problem with supporting that many multicast
addresses per VF is that you run the risk for flooding the PCIe
interface on the network adapter if too many adapters were to go into
such a mode.
> BTW, I'm bit worried about to use ndo interface for 2) because adding a
> new hook makes core code complicated.
> Is it really reasonable to do it with ndo?
> I haven't find any other suitable method to do it, right now. And using
> ndo VF hook looks standard way to control VF functionality.
> Then, I think it's the best way to implement this policy in ndo hook.
The ndo is probably the only way to go on this. It is how past controls
for the VF network functionality have been implemented.
>> In some ways it is almost the mirror image of the issue you brought up:
>>
>> Adding a new hook for this seems over-complicated to me. And it still
>> doesn't solve the real problems that
>> a) the user has to know about this limit, and
>> b) manually configure the feature
>>
>> My reverse argument might be that if this happens automatically. It might take the VM provider a long time to realize
>> performance has taken a hit because some VM asked to join 31 multicast groups and entered MC promiscuous. Then only to
>> find that they have no way to block such behavior.
>>
>> Maybe I wouldn't as concerned if the patch author could provide some performance results to show this won't have as a
>> negative effect as I'm afraid it might?
> Hm, what kind of test case would you like to have?
> The user A who has 30 MC addresses vs the user B who has 31 MC addresses, which
> means that MC promiscuous mode, and coming MC packets the user doesn't expect?
>
> thanks,
> Hiroshi
The question I would have is how many of these interfaces do you expect
to have supporting the expanded multicast mode? As it currently stands
multicast traffic has the potential to flood the adapter, greatly reduce
the overall throughput, and add extra workload to the PF and all VFs.
For example if several VFs enable this feature, and then someone on the
network sends a stream of multicast traffic what happens to the CPU load
for the host system?
Also how many addresses beyond 30 is it you require? An alternative to
adding multicast promiscuous might be to consider extending the mailbox
API to support sending more than 30 addresses via something such as a
multi-part multicast configuration message. The fm10k driver already
has logic similar to this as it adds addresses 1 at a time though a
separate Switch interface API between the PF and the Switch. You might
be able to reuse some of that code to reach beyond the 30 address limit.
- Alex
^ permalink raw reply
* Re: subtle change in behavior with tun driver
From: Michael S. Tsirkin @ 2015-01-23 7:38 UTC (permalink / raw)
To: Ani Sinha; +Cc: fruggeri, netdev@vger.kernel.org
In-Reply-To: <CAOxq_8PCJXw+yoXj0MtLO7nTvWWdR3N4XvKUZ00SX6y-A9EziQ@mail.gmail.com>
On Thu, Jan 22, 2015 at 04:28:09PM -0800, Ani Sinha wrote:
> On Thu, Jan 22, 2015 at 1:53 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Jan 21, 2015 at 02:36:17PM -0800, Ani Sinha wrote:
> >> Hi guys :
> >>
> >> Commit 5d097109257c03 ("tun: only queue packets on device") seems to
> >> have introduced a subtle change in behavior in the tun driver in the
> >> default (non IFF_ONE_QUEUE) case. Previously when the queues got full
> >> and eventually sk_wmem_alloc of the socket exceeded sk_sndbuf value,
> >> the user would be given a feedback by returning EAGAIN from sendto()
> >> etc. That way, the user could retry sending the packet again.
> >
> > This behaviour is common, but by no means guaranteed.
> > For example, if socket buffer size is large enough,
> > packets are small enough, or there are multiple sockets
> > transmitting through tun, packets would previously
> > accumulate in qdisc, followed by packet drops
> > without EAGAIN.
>
> Ah I see. pfifo_fast_enqueue() also starts dropping packets when it's
> length exceeds a threshold. So I supposed we do not have a strong
> argument for bringing back the old semantics because it wasn't
> guranteed in every scenario in the first place.
>
> >
> >> Unfortunately, with this new default single queue mode, the driver
> >> silently drops the packet when the device queue is full without giving
> >> userland any feedback. This makes it appear to userland as though the
> >> packet was transmitted successfully. It seems there is a semantic
> >> change in the driver with this commit.
> >>
> >> If the receiving process gets stuck for a short interval and is unable
> >> to drain packets and then restarts again, one might see strange packet
> >> drops in the kernel without getting any error back on the sender's
> >> side. It kind of feels wrong.
> >>
> >> Any thoughts?
> >>
> >> Ani
> >
> > Unfortunately - since it's pretty common for unpriveledged userspace to
> > drive the tun device - blocking the queue indefinitely as was done
> > previously leads to deadlocks for some apps, this was deemed worse than
> > some performance degradation.
>
> agreed. However applications which needs protection from deadlock can
> exclusively set IFF_ONE_QUEUE mode and live with the fact that they
> might see dropped packets.
This doesn't work because applications are just using the
linux networking stack. Packets end up in tun.
It's up to tun not to break the stack, we can't
change all applications out there.
> >
> > As a simple work-around, if you want packets to accumulate in the qdisc,
> > it's easy to implement by using a non work conserving qdisc.
> > Set the limits to match the speed at which your application
> > is able to consume the packets.
> >
> > I've been thinking about using some kind of watchdog to
> > make it safe to put the old non IFF_ONE_QUEUE semantics back,
> > unfortunately due to application being able to consume packets at the
> > same time it's not trivial to do in a non-racy way.
>
> I do not have an answer to this issue either. I agree that this is a
> hard issue to solve.
^ permalink raw reply
* [PATCH 0/2] ARM EXYNOS5 & net: add fixed phy support
From: Ming Lei @ 2015-01-23 7:48 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller
Cc: linux-samsung-soc, Kukjin Kim, netdev, Byungho An,
Florian Fainelli
Hi,
These two patches adds fixed phy support using the fixed-link DT binding
for stmmac.
Thanks,
Ming Lei
^ 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