* Re: [PATCH] macsec: fix crypto Kconfig dependency
From: David Miller @ 2016-04-18 16:04 UTC (permalink / raw)
To: herbert; +Cc: arnd, sd, hannes, johannes, netdev, linux-kernel
In-Reply-To: <20160418080202.GA18155@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 18 Apr 2016 16:02:02 +0800
> In fact this strikes me as a kbuild bug because CRYPTO_GCM already
> selects (indirectly) CRYPTO_ALGAPI so why is this happening at all?
Selects don't trigger selects.
^ permalink raw reply
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Sinan Kaya @ 2016-04-18 16:06 UTC (permalink / raw)
To: David Miller
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
cov-sgV2jX0FEOL9JmXXK+q4OQ, yishaih-VPRAkNaXOzVWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160418.115902.1053705461620271779.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 4/18/2016 11:59 AM, David Miller wrote:
> From: okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
> Date: Mon, 18 Apr 2016 01:06:27 -0400
>
>> On 2016-04-18 00:00, David Miller wrote:
>>> From: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> Date: Sat, 16 Apr 2016 18:23:32 -0400
>>>
>>>> Current code is assuming that the address returned by
>>>> dma_alloc_coherent
>>>> is a logical address. This is not true on ARM/ARM64 systems. This
>>>> patch
>>>> replaces dma_alloc_coherent with dma_map_page API. The address
>>>> returned
>>>> can later by virtually mapped from the CPU side with vmap API.
>>>> Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> You can't do this.
>>> The DMA map page API gives non-coherent mappings, and thus requires
>>> proper flushing.
>>> So a straight conversion like this is never legitimate.
>>
>> I would agree on proper dma api usage. However, the code is already
>> assuming coherent architecture by mapping the cpu pages as
>> page_kernel.
>>
>> Dma_map_page returns cached buffers and you don't need cache flushes
>> on coherent architecture to make the data visible.
>
> All you are telling me is that there are two bugs instead of one, so now
> both need to be fixed.
>
The removal of vmap also fixes the coherency assumption. It is one fix
for both.
I was thinking of submitting another patch to change the vmap argument
PAGE_KERNEL based on the coherency support of the architecture. I don't need
to do that anymore if the other experiment works.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3] carl9170: Clarify kconfig text
From: Lauri Kasanen @ 2016-04-18 16:07 UTC (permalink / raw)
To: Kalle Valo
Cc: Christian Lamparter, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87shyiyl8a.fsf-5ukZ45wKbUHoml4zekdYB16hYfS7NtTn@public.gmane.org>
The previous text was confusing, leading readers to think this
driver was a duplicate, and so didn't need to be enabled.
After the removal of the older staging driver, this is the only
driver in mainline for these devices.
Signed-off-by: Lauri Kasanen <cand-KK0ffGbhmjU@public.gmane.org>
---
v3: Remove all firmware mentions.
drivers/net/wireless/ath/carl9170/Kconfig | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/Kconfig b/drivers/net/wireless/ath/carl9170/Kconfig
index 1a796e5..ca1ae09 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -5,13 +5,7 @@ config CARL9170
select FW_LOADER
select CRC32
help
- This is another driver for the Atheros "otus" 802.11n USB devices.
-
- This driver provides more features than the original,
- but it needs a special firmware (carl9170-1.fw) to do that.
^ permalink raw reply related
* Re: [PATCH net-next 0/8] allow bpf attach to tracepoints
From: Steven Rostedt @ 2016-04-18 16:13 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Peter Zijlstra, David S . Miller, Ingo Molnar, Daniel Borkmann,
Arnaldo Carvalho de Melo, Wang Nan, Josef Bacik, Brendan Gregg,
netdev, linux-kernel, kernel-team
In-Reply-To: <1459831974-2891931-1-git-send-email-ast@fb.com>
On Mon, 4 Apr 2016 21:52:46 -0700
Alexei Starovoitov <ast@fb.com> wrote:
> Hi Steven, Peter,
>
> last time we discussed bpf+tracepoints it was a year ago [1] and the reason
> we didn't proceed with that approach was that bpf would make arguments
> arg1, arg2 to trace_xx(arg1, arg2) call to be exposed to bpf program
> and that was considered unnecessary extension of abi. Back then I wanted
> to avoid the cost of buffer alloc and field assign part in all
> of the tracepoints, but looks like when optimized the cost is acceptable.
> So this new apporach doesn't expose any new abi to bpf program.
> The program is looking at tracepoint fields after they were copied
> by perf_trace_xx() and described in /sys/kernel/debug/tracing/events/xxx/format
Does this mean that ftrace could use this ability as well? As all the
current filtering of ftrace was done after it was copied to the buffer,
and that was what you wanted to avoid.
-- Steve
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: Alexander Duyck @ 2016-04-18 16:17 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: David Miller, Netdev, linux-kernel@vger.kernel.org, devel, olaf,
Robo Bot, Jason Wang, eli, jackm, yevgenyp, John Ronciak,
intel-wired-lan
In-Reply-To: <1460956969-17601-3-git-send-email-kys@microsoft.com>
On Sun, Apr 17, 2016 at 10:22 PM, K. Y. Srinivasan <kys@microsoft.com> wrote:
> On Hyper-V, the VF/PF communication is a via software mediated path
> as opposed to the hardware mailbox. Make the necessary
> adjustments to support Hyper-V.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> V2: Addressed most of the comments from
> Alexander Duyck <alexander.duyck@gmail.com>
> and Rustad, Mark D <mark.d.rustad@intel.com>.
>
> drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 16 ++-
> drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
> drivers/net/ethernet/intel/ixgbevf/vf.c | 201 +++++++++++++++++++++
> 4 files changed, 237 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> index 5ac60ee..3296d27 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> @@ -460,9 +460,13 @@ enum ixbgevf_state_t {
>
> enum ixgbevf_boards {
> board_82599_vf,
> + board_82599_vf_hv,
> board_X540_vf,
> + board_X540_vf_hv,
> board_X550_vf,
> + board_X550_vf_hv,
> board_X550EM_x_vf,
> + board_X550EM_x_vf_hv,
> };
>
> enum ixgbevf_xcast_modes {
> @@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
> extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
> extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
>
> +
> +extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
> +extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
> +
> /* needed by ethtool.c */
> extern const char ixgbevf_driver_name[];
> extern const char ixgbevf_driver_version[];
> @@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
> void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
> void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
> int ethtool_ioctl(struct ifreq *ifr);
> +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
>
> extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> index 007cbe0..c761d80 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> @@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
> "Copyright (c) 2009 - 2015 Intel Corporation.";
>
> static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> - [board_82599_vf] = &ixgbevf_82599_vf_info,
> - [board_X540_vf] = &ixgbevf_X540_vf_info,
> - [board_X550_vf] = &ixgbevf_X550_vf_info,
> - [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> + [board_82599_vf] = &ixgbevf_82599_vf_info,
> + [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
> + [board_X540_vf] = &ixgbevf_X540_vf_info,
> + [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
> + [board_X550_vf] = &ixgbevf_X550_vf_info,
> + [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
> + [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> + [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
> };
>
> /* ixgbevf_pci_tbl - PCI Device ID Table
> @@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> */
> static const struct pci_device_id ixgbevf_pci_tbl[] = {
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv},
> /* required last entry */
> {0, }
> };
> diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.c b/drivers/net/ethernet/intel/ixgbevf/mbx.c
> index dc68fea..298a0da 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/mbx.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/mbx.c
> @@ -346,3 +346,15 @@ const struct ixgbe_mbx_operations ixgbevf_mbx_ops = {
> .check_for_rst = ixgbevf_check_for_rst_vf,
> };
>
> +/**
> + * Mailbox operations when running on Hyper-V.
> + * On Hyper-V, PF/VF communiction is not through the
> + * hardware mailbox; this communication is through
> + * a software mediated path.
> + * Most mail box operations are noop while running on
> + * Hyper-V.
> + */
> +const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops = {
> + .init_params = ixgbevf_init_mbx_params_vf,
> + .check_for_rst = ixgbevf_check_for_rst_vf,
> +};
> diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
> index 4d613a4..1ec13c1 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/vf.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
> @@ -27,6 +27,13 @@
> #include "vf.h"
> #include "ixgbevf.h"
>
> +/*
> + * On Hyper-V, to reset, we need to read from this offset
> + * from the PCI config space. This is the mechanism used on
> + * Hyper-V to support PF/VF communication.
> + */
> +#define IXGBE_HV_RESET_OFFSET 0x201
> +
> /**
> * ixgbevf_start_hw_vf - Prepare hardware for Tx/Rx
> * @hw: pointer to hardware structure
> @@ -126,6 +133,23 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
> }
>
> /**
> + * Hyper-V variant; the VF/PF communication is through the PCI
> + * config space.
> + */
> +static s32 ixgbevf_hv_reset_hw_vf(struct ixgbe_hw *hw)
> +{
> + struct ixgbevf_adapter *adapter = hw->back;
> + int i;
> +
> + for (i = 0; i < 6; i++)
> + pci_read_config_byte(adapter->pdev,
> + (i + IXGBE_HV_RESET_OFFSET),
> + &hw->mac.perm_addr[i]);
> +
> + return 0;
> +}
> +
I'm still not seeing anything that protects the HyperV VF from being
built with MM_CONFIG disabled. As such this driver will just fail
with no explanation in such a case. If nothing else you could add
some code here that printed an error message if MM_CONFIG is disabled
at the very least.
> +/**
> * ixgbevf_stop_hw_vf - Generic stop Tx/Rx units
> * @hw: pointer to hardware structure
> *
> @@ -258,6 +282,11 @@ static s32 ixgbevf_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
> return ret_val;
> }
>
> +static s32 ixgbevf_hv_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> /**
> * ixgbevf_get_reta_locked - get the RSS redirection table (RETA) contents.
> * @adapter: pointer to the port handle
> @@ -416,6 +445,26 @@ static s32 ixgbevf_set_rar_vf(struct ixgbe_hw *hw, u32 index, u8 *addr,
> return ret_val;
> }
>
> +/**
> + * ixgbevf_hv_set_rar_vf - set device MAC address Hyper-V variant
> + * @hw: pointer to hardware structure
> + * @index: Receive address register to write
> + * @addr: Address to put into receive address register
> + * @vmdq: Unused in this implementation
> + *
> + * We don't really allow setting the device MAC address. However,
> + * if the address being set is the permanent MAC address we will
> + * permit that.
> + **/
> +static s32 ixgbevf_hv_set_rar_vf(struct ixgbe_hw *hw, u32 index, u8 *addr,
> + u32 vmdq)
> +{
> + if (ether_addr_equal(addr, hw->mac.perm_addr))
> + return 0;
> +
> + return -EOPNOTSUPP;
> +}
> +
> static void ixgbevf_write_msg_read_ack(struct ixgbe_hw *hw,
> u32 *msg, u16 size)
> {
> @@ -473,6 +522,15 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
> }
>
> /**
> + * Hyper-V variant - just a stub.
> + */
> +static s32 ixgbevf_hv_update_mc_addr_list_vf(struct ixgbe_hw *hw,
> + struct net_device *netdev)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +/**
> * ixgbevf_update_xcast_mode - Update Multicast mode
> * @hw: pointer to the HW structure
> * @netdev: pointer to net device structure
> @@ -513,6 +571,15 @@ static s32 ixgbevf_update_xcast_mode(struct ixgbe_hw *hw,
> }
>
> /**
> + * Hyper-V variant - just a stub.
> + */
> +static s32 ixgbevf_hv_update_xcast_mode(struct ixgbe_hw *hw,
> + struct net_device *netdev, int xcast_mode)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +/**
> * ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address
> * @hw: pointer to the HW structure
> * @vlan: 12 bit VLAN ID
> @@ -551,6 +618,15 @@ mbx_err:
> }
>
> /**
> + * Hyper-V variant - just a stub.
> + */
> +static s32 ixgbevf_hv_set_vfta_vf(struct ixgbe_hw *hw, u32 vlan, u32 vind,
> + bool vlan_on)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +/**
> * ixgbevf_setup_mac_link_vf - Setup MAC link settings
> * @hw: pointer to hardware structure
> * @speed: Unused in this implementation
> @@ -656,6 +732,67 @@ out:
> }
>
> /**
> + * Hyper-V variant; there is no mailbox communication.
> + */
> +static s32 ixgbevf_hv_check_mac_link_vf(struct ixgbe_hw *hw,
> + ixgbe_link_speed *speed,
> + bool *link_up,
> + bool autoneg_wait_to_complete)
> +{
> + struct ixgbe_mbx_info *mbx = &hw->mbx;
> + struct ixgbe_mac_info *mac = &hw->mac;
> + u32 links_reg;
> +
> + /* If we were hit with a reset drop the link */
> + if (!mbx->ops.check_for_rst(hw) || !mbx->timeout)
> + mac->get_link_status = true;
> +
> + if (!mac->get_link_status)
> + goto out;
> +
> + /* if link status is down no point in checking to see if pf is up */
> + links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
> + if (!(links_reg & IXGBE_LINKS_UP))
> + goto out;
> +
> + /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs
> + * before the link status is correct
> + */
> + if (mac->type == ixgbe_mac_82599_vf) {
> + int i;
> +
> + for (i = 0; i < 5; i++) {
> + udelay(100);
> + links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
> +
> + if (!(links_reg & IXGBE_LINKS_UP))
> + goto out;
> + }
> + }
> +
> + switch (links_reg & IXGBE_LINKS_SPEED_82599) {
> + case IXGBE_LINKS_SPEED_10G_82599:
> + *speed = IXGBE_LINK_SPEED_10GB_FULL;
> + break;
> + case IXGBE_LINKS_SPEED_1G_82599:
> + *speed = IXGBE_LINK_SPEED_1GB_FULL;
> + break;
> + case IXGBE_LINKS_SPEED_100_82599:
> + *speed = IXGBE_LINK_SPEED_100_FULL;
> + break;
> + }
> +
> + /* if we passed all the tests above then the link is up and we no
> + * longer need to check for link
> + */
> + mac->get_link_status = false;
> +
> +out:
> + *link_up = !mac->get_link_status;
> + return 0;
> +}
> +
> +/**
> * ixgbevf_rlpml_set_vf - Set the maximum receive packet length
> * @hw: pointer to the HW structure
> * @max_size: value to assign to max frame size
> @@ -663,6 +800,18 @@ out:
> void ixgbevf_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size)
> {
> u32 msgbuf[2];
> + u32 reg;
> +
> + if (ixgbevf_on_hyperv(hw)) {
> + /* If we are on Hyper-V, we implement
> + * this functionality differently.
> + */
> + reg = IXGBE_READ_REG(hw, IXGBE_VFRXDCTL(0));
> + /* CRC == 4 */
> + reg |= ((max_size + 4) | IXGBE_RXDCTL_RLPML_EN);
> + IXGBE_WRITE_REG(hw, IXGBE_VFRXDCTL(0), reg);
> + return;
> + }
>
> msgbuf[0] = IXGBE_VF_SET_LPE;
> msgbuf[1] = max_size;
There is no point in making this one function. You should split this
code out and create a HyperV version of the function that you can call
instead. It would help to make this more readable anyway since you
can then drop one level of indentation.
> @@ -679,6 +828,15 @@ int ixgbevf_negotiate_api_version(struct ixgbe_hw *hw, int api)
> int err;
> u32 msg[3];
>
> + if (ixgbevf_on_hyperv(hw)) {
> + /* Hyper-V only supports api version ixgbe_mbox_api_10
> + */
> + if (api != ixgbe_mbox_api_10)
> + return IXGBE_ERR_INVALID_ARGUMENT;
> +
> + return 0;
> + }
> +
> /* Negotiate the mailbox API version */
> msg[0] = IXGBE_VF_API_NEGOTIATE;
> msg[1] = api;
Same thing here. You can just create a new function and avoid having
to mess with the mailbox based approach.
> @@ -776,22 +934,65 @@ static const struct ixgbe_mac_operations ixgbevf_mac_ops = {
> .set_vfta = ixgbevf_set_vfta_vf,
> };
>
> +static const struct ixgbe_mac_operations ixgbevf_hv_mac_ops = {
> + .init_hw = ixgbevf_init_hw_vf,
> + .reset_hw = ixgbevf_hv_reset_hw_vf,
> + .start_hw = ixgbevf_start_hw_vf,
> + .get_mac_addr = ixgbevf_get_mac_addr_vf,
> + .stop_adapter = ixgbevf_stop_hw_vf,
> + .setup_link = ixgbevf_setup_mac_link_vf,
> + .check_link = ixgbevf_hv_check_mac_link_vf,
> + .set_rar = ixgbevf_hv_set_rar_vf,
> + .update_mc_addr_list = ixgbevf_hv_update_mc_addr_list_vf,
> + .update_xcast_mode = ixgbevf_hv_update_xcast_mode,
> + .set_uc_addr = ixgbevf_hv_set_uc_addr_vf,
> + .set_vfta = ixgbevf_hv_set_vfta_vf,
> +};
> +
> const struct ixgbevf_info ixgbevf_82599_vf_info = {
> .mac = ixgbe_mac_82599_vf,
> .mac_ops = &ixgbevf_mac_ops,
> };
>
> +const struct ixgbevf_info ixgbevf_82599_vf_hv_info = {
> + .mac = ixgbe_mac_82599_vf,
> + .mac_ops = &ixgbevf_hv_mac_ops,
> +};
> +
> const struct ixgbevf_info ixgbevf_X540_vf_info = {
> .mac = ixgbe_mac_X540_vf,
> .mac_ops = &ixgbevf_mac_ops,
> };
>
> +const struct ixgbevf_info ixgbevf_X540_vf_hv_info = {
> + .mac = ixgbe_mac_X540_vf,
> + .mac_ops = &ixgbevf_hv_mac_ops,
> +};
> +
> const struct ixgbevf_info ixgbevf_X550_vf_info = {
> .mac = ixgbe_mac_X550_vf,
> .mac_ops = &ixgbevf_mac_ops,
> };
>
> +const struct ixgbevf_info ixgbevf_X550_vf_hv_info = {
> + .mac = ixgbe_mac_X550_vf,
> + .mac_ops = &ixgbevf_hv_mac_ops,
> +};
> +
> const struct ixgbevf_info ixgbevf_X550EM_x_vf_info = {
> .mac = ixgbe_mac_X550EM_x_vf,
> .mac_ops = &ixgbevf_mac_ops,
> };
> +
> +const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info = {
> + .mac = ixgbe_mac_X550EM_x_vf,
> + .mac_ops = &ixgbevf_hv_mac_ops,
> +};
> +
> +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw)
> +{
> + if (hw->mbx.ops.check_for_msg == NULL)
> + return true;
> + else
> + return false;
> +}
> --
> 1.7.4.1
>
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@lists.osuosl.org
> http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply
* Re: [PATCH v2] carl9170: Clarify kconfig text
From: Christian Lamparter @ 2016-04-18 16:20 UTC (permalink / raw)
To: Kalle Valo
Cc: Lauri Kasanen, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sgruszka-H+wXaHxf7aLQT0dZR+AlfA,
emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w,
linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <87shyiyl8a.fsf-5ukZ45wKbUHoml4zekdYB16hYfS7NtTn@public.gmane.org>
On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote:
> Lauri Kasanen <cand-KK0ffGbhmjU@public.gmane.org> writes:
>
> > The previous text was confusing, leading readers to think this
> > driver was a duplicate, and so didn't need to be enabled.
> >
> > After the removal of the older staging driver, this is the only
> > driver in mainline for these devices.
> >
> > Signed-off-by: Lauri Kasanen <cand-KK0ffGbhmjU@public.gmane.org>
> > ---
> > v2: Remove the mention of the previous driver, suggested by Christian.
> >
> > drivers/net/wireless/ath/carl9170/Kconfig | 8 +++-----
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/carl9170/Kconfig b/drivers/net/wireless/ath/carl9170/Kconfig
> > index 1a796e5..2e34bae 100644
> > --- a/drivers/net/wireless/ath/carl9170/Kconfig
> > +++ b/drivers/net/wireless/ath/carl9170/Kconfig
> > @@ -5,12 +5,10 @@ config CARL9170
> > select FW_LOADER
> > select CRC32
> > help
> > - This is another driver for the Atheros "otus" 802.11n USB devices.
> > + This is the mainline driver for the Atheros "otus" 802.11n USB devices.
> >
> > - This driver provides more features than the original,
> > - but it needs a special firmware (carl9170-1.fw) to do that.
> > -
> > - The firmware can be downloaded from our wiki here:
> > + It needs a special firmware (carl9170-1.fw), which can be downloaded
> > + from our wiki here:
> > <http://wireless.kernel.org/en/users/Drivers/carl9170>
>
> Why even mention anything about a "special firmware" as the firmware is
> already available from linux-firmware.git?
Yes and no. 1.9.6 is in linux-firmware.git. I've tried to add 1.9.9 too
but that failed.
<http://comments.gmane.org/gmane.linux.kernel.wireless.general/114639>
> That's default location for all firmware images and I think most, if not all,
> distros should have it available. So wouldn't it be better not to mention
> anything about firmware at all?
Sure, but this could be a different patch then. I think Intel devices
(iwlwifi, iwlegacy and ipw2x00) have a similar text about "download
firmware from this device from our homepage here" too. So if we want,
we can remove them altogether?
Regards,
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] carl9170: Clarify kconfig text
From: Christian Lamparter @ 2016-04-18 16:24 UTC (permalink / raw)
To: Lauri Kasanen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <20160418190739.bea7c781e2bd35beb7a748f7@gmx.com>
On Monday, April 18, 2016 07:07:39 PM Lauri Kasanen wrote:
> The previous text was confusing, leading readers to think this
> driver was a duplicate, and so didn't need to be enabled.
>
> After the removal of the older staging driver, this is the only
> driver in mainline for these devices.
>
> Signed-off-by: Lauri Kasanen <cand@gmx.com>
> ---
> v3: Remove all firmware mentions.
>
> drivers/net/wireless/ath/carl9170/Kconfig | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/Kconfig b/drivers/net/wireless/ath/carl9170/Kconfig
> index 1a796e5..ca1ae09 100644
> --- a/drivers/net/wireless/ath/carl9170/Kconfig
> +++ b/drivers/net/wireless/ath/carl9170/Kconfig
> @@ -5,13 +5,7 @@ config CARL9170
> select FW_LOADER
> select CRC32
> help
> - This is another driver for the Atheros "otus" 802.11n USB devices.
> -
> - This driver provides more features than the original,
> - but it needs a special firmware (carl9170-1.fw) to do that.
> -
> - The firmware can be downloaded from our wiki here:
> - <http://wireless.kernel.org/en/users/Drivers/carl9170>
Please do keep the wiki link.
^ permalink raw reply
* RE: Poorer networking performance in later kernels?
From: Butler, Peter @ 2016-04-18 16:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1460981814.10638.104.camel@edumazet-glaptop3.roam.corp.google.com>
Hi Eric
Thanks for your response. My apologies for being late in getting back to you - I wasn't able to have access to the lab hardware on the weekend.
I performed your test as suggested - I've provided a side-by-side diff of the nstat output below for the SCTP test only (not the TCP test). Note that the fields that are output are somewhat different for the two kernels - i.e. some fields exist in one but not the other (presumably this comes from the kernel internals?).
Other than seeing 'larger' throughput numbers in this output I'm not sure what to take from it - I'm certainly not a networking expert :-( Let me know if there's anything that speaks to you.
Note that this test was again done on a clean, freshly rebooted and idle system. Let me know if there's any issues with the output format of this data in the email.
Thanks,
Peter
3.4.2 4.4.0
-------------------------------------------------------------------------------------------------------
IpInReceives 3457295 0.0 | IpInReceives 1151189 0.0
IpInDelivers 3457295 0.0 | IpInDelivers 1151189 0.0
IpOutRequests 6864955 0.0 | IpOutRequests 2249622 0.0
IcmpInErrors 158 0.0 | IcmpInErrors 159 0.0
IcmpInTimeExcds 152 0.0 | IcmpInTimeExcds 151 0.0
IcmpInEchoReps 6 0.0 | IcmpInEchoReps 8 0.0
IcmpOutErrors 158 0.0 | IcmpOutErrors 159 0.0
IcmpOutTimeExcds 152 0.0 | IcmpOutTimeExcds 151 0.0
IcmpOutTimestamps 6 0.0 | IcmpOutTimestamps 8 0.0
IcmpMsgInType3 152 0.0 | IcmpMsgInType3 151 0.0
IcmpMsgInType8 6 0.0 | IcmpMsgInType8 8 0.0
IcmpMsgOutType0 6 0.0 | IcmpMsgOutType0 8 0.0
IcmpMsgOutType3 152 0.0 | IcmpMsgOutType3 151 0.0
TcpActiveOpens 1 0.0 TcpActiveOpens 1 0.0
TcpPassiveOpens 3 0.0 | TcpPassiveOpens 4 0.0
TcpInSegs 70 0.0 | TcpInSegs 117 0.0
TcpOutSegs 66 0.0 | TcpOutSegs 110 0.0
| TcpOutRsts 24 0.0
UdpInDatagrams 608 0.0 | UdpInDatagrams 604 0.0
UdpNoPorts 152 0.0 | UdpNoPorts 151 0.0
UdpOutDatagrams 760 0.0 | UdpOutDatagrams 755 0.0
| UdpIgnoredMulti 144 0.0
TcpExtTW 2 0.0
TcpExtDelayedACKs 3 0.0 | TcpExtDelayedACKs 4 0.0
TcpExtTCPHPHits 25 0.0 | TcpExtTCPHPHits 41 0.0
TcpExtTCPPureAcks 12 0.0 | TcpExtTCPPureAcks 14 0.0
TcpExtTCPHPAcks 18 0.0 | TcpExtTCPHPAcks 26 0.0
| TcpExtTCPRcvCoalesce 12 0.0
| TcpExtTCPOrigDataSent 57 0.0
IpExtInBcastPkts 152 0.0 | IpExtInBcastPkts 144 0.0
IpExtInOctets 166191161 0.0 | IpExtInOctets 55395212 0.0
IpExtOutOctets 9107586685 0.0 | IpExtOutOctets 2983660504 0.0
IpExtInBcastOctets 37356 0.0 | IpExtInBcastOctets 35328 0.0
| IpExtInNoECTPkts 1175 0.0
| IpExtInECT0Pkts 1150014 0.0
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: April-18-16 8:17 AM
To: Butler, Peter <pbutler@sonusnet.com>
Cc: netdev@vger.kernel.org
Subject: Re: Poorer networking performance in later kernels?
On Fri, 2016-04-15 at 15:33 -0700, Eric Dumazet wrote:
> On Fri, 2016-04-15 at 21:02 +0000, Butler, Peter wrote:
> > (Please keep me CC'd to all comments/responses)
> >
> > I've tried a kernel upgrade from 3.4.2 to 4.4.0 and see a marked drop in networking performance. Nothing was changed on the test systems, other than the kernel itself (and kernel modules). The identical .config used to build the 3.4.2 kernel was brought over into the 4.4.0 kernel source tree, and any configuration differences (e.g. new parameters, etc.) were taken as default values.
> >
> > The testing was performed on the same actual hardware for both kernel versions (i.e. take the existing 3.4.2 physical setup, simply boot into the (new) kernel and run the same test). The netperf utility was used for benchmarking and the testing was always performed on idle systems.
> >
> > TCP testing yielded the following results, where the 4.4.0 kernel only got about 1/2 of the throughput:
> >
> > Recv Send Send Utilization Service Demand
> > Socket Socket Message Elapsed Send Recv Send Recv
> > Size Size Size Time Throughput local remote local remote
> > bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
> >
> > 3.4.2 13631488 13631488 8952 30.01 9370.29 10.14 6.50 0.709 0.454
> > 4.4.0 13631488 13631488 8952 30.02 5314.03 9.14 14.31 1.127 1.765
> >
> > SCTP testing yielded the following results, where the 4.4.0 kernel only got about 1/3 of the throughput:
> >
> > Recv Send Send Utilization Service Demand
> > Socket Socket Message Elapsed Send Recv Send Recv
> > Size Size Size Time Throughput local remote local remote
> > bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
> >
> > 3.4.2 13631488 13631488 8952 30.00 2306.22 13.87 13.19 3.941 3.747
> > 4.4.0 13631488 13631488 8952 30.01 882.74 16.86 19.14 12.516 14.210
> >
> > The same tests were performed a multitude of time, and are always consistent (within a few percent). I've also tried playing with various run-time kernel parameters (/proc/sys/kernel/net/...) on the 4.4.0 kernel to alleviate the issue but have had no success at all.
> >
> > I'm at a loss as to what could possibly account for such a discrepancy...
>
> Maybe new kernel is faster and you have drops somewhere ?
>
> nstat >/dev/null
> netperf -H ...
> nstat
>
> Would help
>
Are you receiving my mails, or simply ignoring them ?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v4] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: David Miller @ 2016-04-18 16:28 UTC (permalink / raw)
To: roopa; +Cc: netdev, jhs, tgraf
In-Reply-To: <1460957735-44337-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Sun, 17 Apr 2016 22:35:35 -0700
> This patch adds a new RTM_GETSTATS message to query link stats via netlink
> from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
> returns a lot more than just stats and is expensive in some cases when
> frequent polling for stats from userspace is a common operation.
The following build failure needs to be resolved:
security/selinux/nlmsgtab.c: In function ‘selinux_nlmsg_lookup’:
include/linux/compiler.h:506:38: error: call to ‘__compiletime_assert_158’ declared with attribute error: BUILD_BUG_ON failed: RTM_MAX != (RTM_NEWNSID + 3)
^ permalink raw reply
* Re: [PATCH v2] carl9170: Clarify kconfig text
From: Kalle Valo @ 2016-04-18 16:42 UTC (permalink / raw)
To: Christian Lamparter
Cc: Lauri Kasanen, linux-wireless, netdev, linux-kernel, sgruszka,
emmanuel.grumbach, linuxwifi, johannes.berg, emmanuel.grumbach
In-Reply-To: <3244016.0TmHG3E4A9@debian64>
Christian Lamparter <chunkeey@googlemail.com> writes:
> On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote:
>> Lauri Kasanen <cand@gmx.com> writes:
>>
>> > --- a/drivers/net/wireless/ath/carl9170/Kconfig
>> > +++ b/drivers/net/wireless/ath/carl9170/Kconfig
>> > @@ -5,12 +5,10 @@ config CARL9170
>> > select FW_LOADER
>> > select CRC32
>> > help
>> > - This is another driver for the Atheros "otus" 802.11n USB devices.
>> > + This is the mainline driver for the Atheros "otus" 802.11n USB devices.
>> >
>> > - This driver provides more features than the original,
>> > - but it needs a special firmware (carl9170-1.fw) to do that.
>> > -
>> > - The firmware can be downloaded from our wiki here:
>> > + It needs a special firmware (carl9170-1.fw), which can be downloaded
>> > + from our wiki here:
>> > <http://wireless.kernel.org/en/users/Drivers/carl9170>
>>
>> Why even mention anything about a "special firmware" as the firmware is
>> already available from linux-firmware.git?
>
> Yes and no. 1.9.6 is in linux-firmware.git. I've tried to add 1.9.9 too
> but that failed.
> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/114639>
Rick's comment makes sense to me, better just to provide the latest
version. No need to unnecessary confuse the users. And if someone really
wants to use an older version that she can retrieve it from the git
history.
>> That's default location for all firmware images and I think most, if not all,
>> distros should have it available. So wouldn't it be better not to mention
>> anything about firmware at all?
>
> Sure, but this could be a different patch then. I think Intel devices
> (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download
> firmware from this device from our homepage here" too. So if we want,
> we can remove them altogether?
So iwlwifi now has:
In order to use this driver, you will need a firmware
image for it. You can obtain the microcode from:
<http://wireless.kernel.org/en/users/Drivers/iwlwifi>.
Maybe that could be changed to mention about the wiki page in general:
The driver has a wiki page at:
<http://wireless.kernel.org/en/users/Drivers/iwlwifi>.
But I know iwlwifi updates the firmware images pretty often so Emmanuel
might see this differently.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] macsec: fix crypto Kconfig dependency
From: David Miller @ 2016-04-18 16:43 UTC (permalink / raw)
To: herbert; +Cc: arnd, sd, hannes, johannes, netdev, linux-kernel
In-Reply-To: <20160418104336.GA19175@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 18 Apr 2016 18:43:36 +0800
> Right, the problem is that nothing within crypto ever selects
> CRYPTO since it's also used as a way of hiding the crypto menu
> options.
As far as I understand it, this won't help. Because selects do not
trigger other selects and dependencies.
This is why we always must list all leaf node dependencies with select
statements, rather than just the specific feature one needs.
^ permalink raw reply
* RE: Poorer networking performance in later kernels?
From: Butler, Peter @ 2016-04-18 16:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1460981814.10638.104.camel@edumazet-glaptop3.roam.corp.google.com>
P.S. Cancel my comment about some fields existing in one kernel but not the other- that was probably just an artefact of the fact that for one kernel the value was zero but not in the other kernel (and that I did not run nstat with the -z option to output zero counts). So the data I provided is still good, but the 'empty' fields that exist in one kernel or the other can safely be assumed to be zero counts where left out.
-----Original Message-----
From: Butler, Peter
Sent: April-18-16 12:27 PM
To: 'Eric Dumazet' <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org
Subject: RE: Poorer networking performance in later kernels?
Hi Eric
Thanks for your response. My apologies for being late in getting back to you - I wasn't able to have access to the lab hardware on the weekend.
I performed your test as suggested - I've provided a side-by-side diff of the nstat output below for the SCTP test only (not the TCP test). Note that the fields that are output are somewhat different for the two kernels - i.e. some fields exist in one but not the other (presumably this comes from the kernel internals?).
Other than seeing 'larger' throughput numbers in this output I'm not sure what to take from it - I'm certainly not a networking expert :-( Let me know if there's anything that speaks to you.
Note that this test was again done on a clean, freshly rebooted and idle system. Let me know if there's any issues with the output format of this data in the email.
Thanks,
Peter
3.4.2 4.4.0
-------------------------------------------------------------------------------------------------------
IpInReceives 3457295 0.0 | IpInReceives 1151189 0.0
IpInDelivers 3457295 0.0 | IpInDelivers 1151189 0.0
IpOutRequests 6864955 0.0 | IpOutRequests 2249622 0.0
IcmpInErrors 158 0.0 | IcmpInErrors 159 0.0
IcmpInTimeExcds 152 0.0 | IcmpInTimeExcds 151 0.0
IcmpInEchoReps 6 0.0 | IcmpInEchoReps 8 0.0
IcmpOutErrors 158 0.0 | IcmpOutErrors 159 0.0
IcmpOutTimeExcds 152 0.0 | IcmpOutTimeExcds 151 0.0
IcmpOutTimestamps 6 0.0 | IcmpOutTimestamps 8 0.0
IcmpMsgInType3 152 0.0 | IcmpMsgInType3 151 0.0
IcmpMsgInType8 6 0.0 | IcmpMsgInType8 8 0.0
IcmpMsgOutType0 6 0.0 | IcmpMsgOutType0 8 0.0
IcmpMsgOutType3 152 0.0 | IcmpMsgOutType3 151 0.0
TcpActiveOpens 1 0.0 TcpActiveOpens 1 0.0
TcpPassiveOpens 3 0.0 | TcpPassiveOpens 4 0.0
TcpInSegs 70 0.0 | TcpInSegs 117 0.0
TcpOutSegs 66 0.0 | TcpOutSegs 110 0.0
| TcpOutRsts 24 0.0
UdpInDatagrams 608 0.0 | UdpInDatagrams 604 0.0
UdpNoPorts 152 0.0 | UdpNoPorts 151 0.0
UdpOutDatagrams 760 0.0 | UdpOutDatagrams 755 0.0
| UdpIgnoredMulti 144 0.0
TcpExtTW 2 0.0
TcpExtDelayedACKs 3 0.0 | TcpExtDelayedACKs 4 0.0
TcpExtTCPHPHits 25 0.0 | TcpExtTCPHPHits 41 0.0
TcpExtTCPPureAcks 12 0.0 | TcpExtTCPPureAcks 14 0.0
TcpExtTCPHPAcks 18 0.0 | TcpExtTCPHPAcks 26 0.0
| TcpExtTCPRcvCoalesce 12 0.0
| TcpExtTCPOrigDataSent 57 0.0
IpExtInBcastPkts 152 0.0 | IpExtInBcastPkts 144 0.0
IpExtInOctets 166191161 0.0 | IpExtInOctets 55395212 0.0
IpExtOutOctets 9107586685 0.0 | IpExtOutOctets 2983660504 0.0
IpExtInBcastOctets 37356 0.0 | IpExtInBcastOctets 35328 0.0
| IpExtInNoECTPkts 1175 0.0
| IpExtInECT0Pkts 1150014 0.0
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: April-18-16 8:17 AM
To: Butler, Peter <pbutler@sonusnet.com>
Cc: netdev@vger.kernel.org
Subject: Re: Poorer networking performance in later kernels?
On Fri, 2016-04-15 at 15:33 -0700, Eric Dumazet wrote:
> On Fri, 2016-04-15 at 21:02 +0000, Butler, Peter wrote:
> > (Please keep me CC'd to all comments/responses)
> >
> > I've tried a kernel upgrade from 3.4.2 to 4.4.0 and see a marked drop in networking performance. Nothing was changed on the test systems, other than the kernel itself (and kernel modules). The identical .config used to build the 3.4.2 kernel was brought over into the 4.4.0 kernel source tree, and any configuration differences (e.g. new parameters, etc.) were taken as default values.
> >
> > The testing was performed on the same actual hardware for both kernel versions (i.e. take the existing 3.4.2 physical setup, simply boot into the (new) kernel and run the same test). The netperf utility was used for benchmarking and the testing was always performed on idle systems.
> >
> > TCP testing yielded the following results, where the 4.4.0 kernel only got about 1/2 of the throughput:
> >
> > Recv Send Send Utilization Service Demand
> > Socket Socket Message Elapsed Send Recv Send Recv
> > Size Size Size Time Throughput local remote local remote
> > bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
> >
> > 3.4.2 13631488 13631488 8952 30.01 9370.29 10.14 6.50 0.709 0.454
> > 4.4.0 13631488 13631488 8952 30.02 5314.03 9.14 14.31 1.127 1.765
> >
> > SCTP testing yielded the following results, where the 4.4.0 kernel only got about 1/3 of the throughput:
> >
> > Recv Send Send Utilization Service Demand
> > Socket Socket Message Elapsed Send Recv Send Recv
> > Size Size Size Time Throughput local remote local remote
> > bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
> >
> > 3.4.2 13631488 13631488 8952 30.00 2306.22 13.87 13.19 3.941 3.747
> > 4.4.0 13631488 13631488 8952 30.01 882.74 16.86 19.14 12.516 14.210
> >
> > The same tests were performed a multitude of time, and are always consistent (within a few percent). I've also tried playing with various run-time kernel parameters (/proc/sys/kernel/net/...) on the 4.4.0 kernel to alleviate the issue but have had no success at all.
> >
> > I'm at a loss as to what could possibly account for such a discrepancy...
>
> Maybe new kernel is faster and you have drops somewhere ?
>
> nstat >/dev/null
> netperf -H ...
> nstat
>
> Would help
>
Are you receiving my mails, or simply ignoring them ?
Thanks.
^ permalink raw reply
* Re: [PATCH v2] carl9170: Clarify kconfig text
From: Xose Vazquez Perez @ 2016-04-18 16:47 UTC (permalink / raw)
To: Christian Lamparter, Lauri Kasanen, Kalle Valo, LKML,
linux-wireless, netdev, Linux Firmware Maintainers
Christian Lamparter wrote:
> Sure, but this could be a different patch then. I think Intel devices
> (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download
> firmware from this device from our homepage here" too. So if we want,
> we can remove them altogether?
linux-firmware.git does not contain firmware for all drivers. _At least_
zd1211rw [1], atmel [2] and ipw2x00 [3] are out of the tree.
[1] http://sf.net/projects/zd1211/files/
[2] http://web.archive.org/web/20121016132320/http://at76c503a.berlios.de/fw_dl.html
[3] http://ipw2100.sf.net/firmware.php http://ipw2200.sf.net/firmware.php
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: KY Srinivasan @ 2016-04-18 16:52 UTC (permalink / raw)
To: Alexander Duyck
Cc: olaf@aepfle.de, Netdev, Jason Wang, linux-kernel@vger.kernel.org,
jackm@mellanox.com, yevgenyp@mellanox.com, John Ronciak,
intel-wired-lan, eli@mellanox.com, Robo Bot,
devel@linuxdriverproject.org, David Miller
In-Reply-To: <CAKgT0UdLxSk6CKVAt232fdthMtUbn9FLru9Q9w1Qjjdv_zKA4g@mail.gmail.com>
> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> Sent: Monday, April 18, 2016 9:18 AM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: David Miller <davem@davemloft.net>; Netdev
> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; Robo Bot
> <apw@canonical.com>; Jason Wang <jasowang@redhat.com>;
> eli@mellanox.com; jackm@mellanox.com; yevgenyp@mellanox.com; John
> Ronciak <john.ronciak@intel.com>; intel-wired-lan <intel-wired-
> lan@lists.osuosl.org>
> Subject: Re: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support
> Windows hosts (Hyper-V)
>
> On Sun, Apr 17, 2016 at 10:22 PM, K. Y. Srinivasan <kys@microsoft.com>
> wrote:
> > On Hyper-V, the VF/PF communication is a via software mediated path
> > as opposed to the hardware mailbox. Make the necessary
> > adjustments to support Hyper-V.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > V2: Addressed most of the comments from
> > Alexander Duyck <alexander.duyck@gmail.com>
> > and Rustad, Mark D <mark.d.rustad@intel.com>.
> >
> > drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
> > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 16 ++-
> > drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
> > drivers/net/ethernet/intel/ixgbevf/vf.c | 201
> +++++++++++++++++++++
> > 4 files changed, 237 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > index 5ac60ee..3296d27 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > @@ -460,9 +460,13 @@ enum ixbgevf_state_t {
> >
> > enum ixgbevf_boards {
> > board_82599_vf,
> > + board_82599_vf_hv,
> > board_X540_vf,
> > + board_X540_vf_hv,
> > board_X550_vf,
> > + board_X550_vf_hv,
> > board_X550EM_x_vf,
> > + board_X550EM_x_vf_hv,
> > };
> >
> > enum ixgbevf_xcast_modes {
> > @@ -477,6 +481,13 @@ extern const struct ixgbevf_info
> ixgbevf_X550_vf_info;
> > extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
> > extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
> >
> > +
> > +extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
> > +extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
> > +
> > /* needed by ethtool.c */
> > extern const char ixgbevf_driver_name[];
> > extern const char ixgbevf_driver_version[];
> > @@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring
> *);
> > void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
> > void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
> > int ethtool_ioctl(struct ifreq *ifr);
> > +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
> >
> > extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > index 007cbe0..c761d80 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > @@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
> > "Copyright (c) 2009 - 2015 Intel Corporation.";
> >
> > static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> > - [board_82599_vf] = &ixgbevf_82599_vf_info,
> > - [board_X540_vf] = &ixgbevf_X540_vf_info,
> > - [board_X550_vf] = &ixgbevf_X550_vf_info,
> > - [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> > + [board_82599_vf] = &ixgbevf_82599_vf_info,
> > + [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
> > + [board_X540_vf] = &ixgbevf_X540_vf_info,
> > + [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
> > + [board_X550_vf] = &ixgbevf_X550_vf_info,
> > + [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
> > + [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> > + [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
> > };
> >
> > /* ixgbevf_pci_tbl - PCI Device ID Table
> > @@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] =
> {
> > */
> > static const struct pci_device_id ixgbevf_pci_tbl[] = {
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
> > + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV),
> board_82599_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
> > + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV),
> board_X540_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
> > + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV),
> board_X550_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF),
> board_X550EM_x_vf },
> > + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV),
> board_X550EM_x_vf_hv},
> > /* required last entry */
> > {0, }
> > };
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.c
> b/drivers/net/ethernet/intel/ixgbevf/mbx.c
> > index dc68fea..298a0da 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/mbx.c
> > +++ b/drivers/net/ethernet/intel/ixgbevf/mbx.c
> > @@ -346,3 +346,15 @@ const struct ixgbe_mbx_operations
> ixgbevf_mbx_ops = {
> > .check_for_rst = ixgbevf_check_for_rst_vf,
> > };
> >
> > +/**
> > + * Mailbox operations when running on Hyper-V.
> > + * On Hyper-V, PF/VF communiction is not through the
> > + * hardware mailbox; this communication is through
> > + * a software mediated path.
> > + * Most mail box operations are noop while running on
> > + * Hyper-V.
> > + */
> > +const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops = {
> > + .init_params = ixgbevf_init_mbx_params_vf,
> > + .check_for_rst = ixgbevf_check_for_rst_vf,
> > +};
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c
> b/drivers/net/ethernet/intel/ixgbevf/vf.c
> > index 4d613a4..1ec13c1 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/vf.c
> > +++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
> > @@ -27,6 +27,13 @@
> > #include "vf.h"
> > #include "ixgbevf.h"
> >
> > +/*
> > + * On Hyper-V, to reset, we need to read from this offset
> > + * from the PCI config space. This is the mechanism used on
> > + * Hyper-V to support PF/VF communication.
> > + */
> > +#define IXGBE_HV_RESET_OFFSET 0x201
> > +
> > /**
> > * ixgbevf_start_hw_vf - Prepare hardware for Tx/Rx
> > * @hw: pointer to hardware structure
> > @@ -126,6 +133,23 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw
> *hw)
> > }
> >
> > /**
> > + * Hyper-V variant; the VF/PF communication is through the PCI
> > + * config space.
> > + */
> > +static s32 ixgbevf_hv_reset_hw_vf(struct ixgbe_hw *hw)
> > +{
> > + struct ixgbevf_adapter *adapter = hw->back;
> > + int i;
> > +
> > + for (i = 0; i < 6; i++)
> > + pci_read_config_byte(adapter->pdev,
> > + (i + IXGBE_HV_RESET_OFFSET),
> > + &hw->mac.perm_addr[i]);
> > +
> > + return 0;
> > +}
> > +
>
> I'm still not seeing anything that protects the HyperV VF from being
> built with MM_CONFIG disabled. As such this driver will just fail
> with no explanation in such a case. If nothing else you could add
> some code here that printed an error message if MM_CONFIG is disabled
> at the very least.
I will add the error message.
>
> > +/**
> > * ixgbevf_stop_hw_vf - Generic stop Tx/Rx units
> > * @hw: pointer to hardware structure
> > *
> > @@ -258,6 +282,11 @@ static s32 ixgbevf_set_uc_addr_vf(struct ixgbe_hw
> *hw, u32 index, u8 *addr)
> > return ret_val;
> > }
> >
> > +static s32 ixgbevf_hv_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index,
> u8 *addr)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > +
> > /**
> > * ixgbevf_get_reta_locked - get the RSS redirection table (RETA)
> contents.
> > * @adapter: pointer to the port handle
> > @@ -416,6 +445,26 @@ static s32 ixgbevf_set_rar_vf(struct ixgbe_hw
> *hw, u32 index, u8 *addr,
> > return ret_val;
> > }
> >
> > +/**
> > + * ixgbevf_hv_set_rar_vf - set device MAC address Hyper-V variant
> > + * @hw: pointer to hardware structure
> > + * @index: Receive address register to write
> > + * @addr: Address to put into receive address register
> > + * @vmdq: Unused in this implementation
> > + *
> > + * We don't really allow setting the device MAC address. However,
> > + * if the address being set is the permanent MAC address we will
> > + * permit that.
> > + **/
> > +static s32 ixgbevf_hv_set_rar_vf(struct ixgbe_hw *hw, u32 index, u8
> *addr,
> > + u32 vmdq)
> > +{
> > + if (ether_addr_equal(addr, hw->mac.perm_addr))
> > + return 0;
> > +
> > + return -EOPNOTSUPP;
> > +}
> > +
> > static void ixgbevf_write_msg_read_ack(struct ixgbe_hw *hw,
> > u32 *msg, u16 size)
> > {
> > @@ -473,6 +522,15 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct
> ixgbe_hw *hw,
> > }
> >
> > /**
> > + * Hyper-V variant - just a stub.
> > + */
> > +static s32 ixgbevf_hv_update_mc_addr_list_vf(struct ixgbe_hw *hw,
> > + struct net_device *netdev)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > +
> > +/**
> > * ixgbevf_update_xcast_mode - Update Multicast mode
> > * @hw: pointer to the HW structure
> > * @netdev: pointer to net device structure
> > @@ -513,6 +571,15 @@ static s32 ixgbevf_update_xcast_mode(struct
> ixgbe_hw *hw,
> > }
> >
> > /**
> > + * Hyper-V variant - just a stub.
> > + */
> > +static s32 ixgbevf_hv_update_xcast_mode(struct ixgbe_hw *hw,
> > + struct net_device *netdev, int xcast_mode)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > +
> > +/**
> > * ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address
> > * @hw: pointer to the HW structure
> > * @vlan: 12 bit VLAN ID
> > @@ -551,6 +618,15 @@ mbx_err:
> > }
> >
> > /**
> > + * Hyper-V variant - just a stub.
> > + */
> > +static s32 ixgbevf_hv_set_vfta_vf(struct ixgbe_hw *hw, u32 vlan, u32
> vind,
> > + bool vlan_on)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > +
> > +/**
> > * ixgbevf_setup_mac_link_vf - Setup MAC link settings
> > * @hw: pointer to hardware structure
> > * @speed: Unused in this implementation
> > @@ -656,6 +732,67 @@ out:
> > }
> >
> > /**
> > + * Hyper-V variant; there is no mailbox communication.
> > + */
> > +static s32 ixgbevf_hv_check_mac_link_vf(struct ixgbe_hw *hw,
> > + ixgbe_link_speed *speed,
> > + bool *link_up,
> > + bool autoneg_wait_to_complete)
> > +{
> > + struct ixgbe_mbx_info *mbx = &hw->mbx;
> > + struct ixgbe_mac_info *mac = &hw->mac;
> > + u32 links_reg;
> > +
> > + /* If we were hit with a reset drop the link */
> > + if (!mbx->ops.check_for_rst(hw) || !mbx->timeout)
> > + mac->get_link_status = true;
> > +
> > + if (!mac->get_link_status)
> > + goto out;
> > +
> > + /* if link status is down no point in checking to see if pf is up */
> > + links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
> > + if (!(links_reg & IXGBE_LINKS_UP))
> > + goto out;
> > +
> > + /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs
> > + * before the link status is correct
> > + */
> > + if (mac->type == ixgbe_mac_82599_vf) {
> > + int i;
> > +
> > + for (i = 0; i < 5; i++) {
> > + udelay(100);
> > + links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
> > +
> > + if (!(links_reg & IXGBE_LINKS_UP))
> > + goto out;
> > + }
> > + }
> > +
> > + switch (links_reg & IXGBE_LINKS_SPEED_82599) {
> > + case IXGBE_LINKS_SPEED_10G_82599:
> > + *speed = IXGBE_LINK_SPEED_10GB_FULL;
> > + break;
> > + case IXGBE_LINKS_SPEED_1G_82599:
> > + *speed = IXGBE_LINK_SPEED_1GB_FULL;
> > + break;
> > + case IXGBE_LINKS_SPEED_100_82599:
> > + *speed = IXGBE_LINK_SPEED_100_FULL;
> > + break;
> > + }
> > +
> > + /* if we passed all the tests above then the link is up and we no
> > + * longer need to check for link
> > + */
> > + mac->get_link_status = false;
> > +
> > +out:
> > + *link_up = !mac->get_link_status;
> > + return 0;
> > +}
> > +
> > +/**
> > * ixgbevf_rlpml_set_vf - Set the maximum receive packet length
> > * @hw: pointer to the HW structure
> > * @max_size: value to assign to max frame size
> > @@ -663,6 +800,18 @@ out:
> > void ixgbevf_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size)
> > {
> > u32 msgbuf[2];
> > + u32 reg;
> > +
> > + if (ixgbevf_on_hyperv(hw)) {
> > + /* If we are on Hyper-V, we implement
> > + * this functionality differently.
> > + */
> > + reg = IXGBE_READ_REG(hw, IXGBE_VFRXDCTL(0));
> > + /* CRC == 4 */
> > + reg |= ((max_size + 4) | IXGBE_RXDCTL_RLPML_EN);
> > + IXGBE_WRITE_REG(hw, IXGBE_VFRXDCTL(0), reg);
> > + return;
> > + }
> >
> > msgbuf[0] = IXGBE_VF_SET_LPE;
> > msgbuf[1] = max_size;
>
> There is no point in making this one function. You should split this
> code out and create a HyperV version of the function that you can call
> instead. It would help to make this more readable anyway since you
> can then drop one level of indentation.
I will split the function as you have suggested.
>
> > @@ -679,6 +828,15 @@ int ixgbevf_negotiate_api_version(struct
> ixgbe_hw *hw, int api)
> > int err;
> > u32 msg[3];
> >
> > + if (ixgbevf_on_hyperv(hw)) {
> > + /* Hyper-V only supports api version ixgbe_mbox_api_10
> > + */
> > + if (api != ixgbe_mbox_api_10)
> > + return IXGBE_ERR_INVALID_ARGUMENT;
> > +
> > + return 0;
> > + }
> > +
> > /* Negotiate the mailbox API version */
> > msg[0] = IXGBE_VF_API_NEGOTIATE;
> > msg[1] = api;
>
> Same thing here. You can just create a new function and avoid having
> to mess with the mailbox based approach.
I will split the function as you have suggested.
>
> > @@ -776,22 +934,65 @@ static const struct ixgbe_mac_operations
> ixgbevf_mac_ops = {
> > .set_vfta = ixgbevf_set_vfta_vf,
> > };
> >
> > +static const struct ixgbe_mac_operations ixgbevf_hv_mac_ops = {
> > + .init_hw = ixgbevf_init_hw_vf,
> > + .reset_hw = ixgbevf_hv_reset_hw_vf,
> > + .start_hw = ixgbevf_start_hw_vf,
> > + .get_mac_addr = ixgbevf_get_mac_addr_vf,
> > + .stop_adapter = ixgbevf_stop_hw_vf,
> > + .setup_link = ixgbevf_setup_mac_link_vf,
> > + .check_link = ixgbevf_hv_check_mac_link_vf,
> > + .set_rar = ixgbevf_hv_set_rar_vf,
> > + .update_mc_addr_list = ixgbevf_hv_update_mc_addr_list_vf,
> > + .update_xcast_mode = ixgbevf_hv_update_xcast_mode,
> > + .set_uc_addr = ixgbevf_hv_set_uc_addr_vf,
> > + .set_vfta = ixgbevf_hv_set_vfta_vf,
> > +};
> > +
> > const struct ixgbevf_info ixgbevf_82599_vf_info = {
> > .mac = ixgbe_mac_82599_vf,
> > .mac_ops = &ixgbevf_mac_ops,
> > };
> >
> > +const struct ixgbevf_info ixgbevf_82599_vf_hv_info = {
> > + .mac = ixgbe_mac_82599_vf,
> > + .mac_ops = &ixgbevf_hv_mac_ops,
> > +};
> > +
> > const struct ixgbevf_info ixgbevf_X540_vf_info = {
> > .mac = ixgbe_mac_X540_vf,
> > .mac_ops = &ixgbevf_mac_ops,
> > };
> >
> > +const struct ixgbevf_info ixgbevf_X540_vf_hv_info = {
> > + .mac = ixgbe_mac_X540_vf,
> > + .mac_ops = &ixgbevf_hv_mac_ops,
> > +};
> > +
> > const struct ixgbevf_info ixgbevf_X550_vf_info = {
> > .mac = ixgbe_mac_X550_vf,
> > .mac_ops = &ixgbevf_mac_ops,
> > };
> >
> > +const struct ixgbevf_info ixgbevf_X550_vf_hv_info = {
> > + .mac = ixgbe_mac_X550_vf,
> > + .mac_ops = &ixgbevf_hv_mac_ops,
> > +};
> > +
> > const struct ixgbevf_info ixgbevf_X550EM_x_vf_info = {
> > .mac = ixgbe_mac_X550EM_x_vf,
> > .mac_ops = &ixgbevf_mac_ops,
> > };
> > +
> > +const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info = {
> > + .mac = ixgbe_mac_X550EM_x_vf,
> > + .mac_ops = &ixgbevf_hv_mac_ops,
> > +};
> > +
> > +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw)
> > +{
> > + if (hw->mbx.ops.check_for_msg == NULL)
> > + return true;
> > + else
> > + return false;
> > +}
> > --
> > 1.7.4.1
Thank you.
K. Y
> >
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan@lists.osuosl.org
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.osu
> osl.org%2fmailman%2flistinfo%2fintel-wired-
> lan&data=01%7c01%7ckys%40microsoft.com%7cfdaf85b858e240c2e38108d3
> 67a4f2d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Vf%2fXiRxqiEa
> OaUMQNN9kM1A12IV5JCkEXVILgAEFbYI%3d
^ permalink raw reply
* RE: switchdev fib offload issues
From: Ilan Tayari @ 2016-04-18 16:38 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev@vger.kernel.org
In-Reply-To: <20160418154757.GA2059@nanopsycho.amit.cz>
Hi Jiri,
> Thoughts?
One general thought comes to mind, regardless of your proposed solutions:
You'll need to take care to propagate the error properly in case of routes created by the kernel, such as local routes.
Local routes are created when an IP address is added to an interface, so in such a case would the whole add-ip-address operation be rolled back cleanly?
Ilan.
^ permalink raw reply
* Re: switchdev fib offload issues
From: David Ahern @ 2016-04-18 16:59 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, idosch, eladr, yotamg, ogerlitz, roopa, nikolay, jhs,
john.fastabend, rami.rosen, gospo, stephen, sfeldma, f.fainelli,
andrew, vivien.didelot, tgraf, aduyck
In-Reply-To: <20160418154757.GA2059@nanopsycho.amit.cz>
On 4/18/16 9:47 AM, Jiri Pirko wrote:
> Proposed solutions (ideas):
> 1) per-netns. Add a procfs file:
> /proc/sys/net/ipv4/route/fib_offload_error_policy
> with values: "evict" - default, current behaviour
> "fail" - propagate offload error to user
> The policy value would be stored in struct net.
>
> 2) per-VRF/table
> When user creates a VRF master, he specifies a table ID
> this VRF is going to use. I propose to extend this so
> he can pass a policy ("evict"/"fail").
> The policy value would be stored in struct fib_table or
> struct fib6_table. The problem is that vfr only saves
> table ID, allocates dst but does not actually create
> table. That might be created later. But I think this
> could be resolved.
Yes, we have a local patch where I do create the table for IPv6. Can do
that for IPv4 as well. Some other clean ups are needed in this area -
like the ability to delete a table
>
> 3) per-VFR/master_netdev
> In this case, the policy would be also set during
> the creation of VFR master. From user perspective,
> this looks same as 2)
> The policy value would be stored in struct net_vrf (vrf private).
The VRF device is really only used for guiding lookups, not inserting
routes.
A per table/VRF policy (option 2) seems more appropriate.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: Joe Perches @ 2016-04-18 17:00 UTC (permalink / raw)
To: KY Srinivasan, Alexander Duyck
Cc: olaf@aepfle.de, Netdev, Jason Wang, linux-kernel@vger.kernel.org,
jackm@mellanox.com, yevgenyp@mellanox.com, John Ronciak,
intel-wired-lan, eli@mellanox.com, Robo Bot,
devel@linuxdriverproject.org, David Miller
In-Reply-To: <BL2PR03MB19081E9C9AAB13E6F608D08FA06B0@BL2PR03MB1908.namprd03.prod.outlook.com>
On Mon, 2016-04-18 at 16:52 +0000, KY Srinivasan wrote:
[]
> > > +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw)
> > > +{
> > > + if (hw->mbx.ops.check_for_msg == NULL)
> > > + return true;
> > > + else
> > > + return false;
> > > +}
trivia:
bool func(...)
{
if (<bar>)
return true;
else
return false;
}
can generally be written as:
bool func(...)
{
return <bar>;
}
^ permalink raw reply
* Re: [PATCH v2] carl9170: Clarify kconfig text
From: Christian Lamparter @ 2016-04-18 17:07 UTC (permalink / raw)
To: Kalle Valo
Cc: Lauri Kasanen, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87r3e2kgwy.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On Monday, April 18, 2016 07:42:05 PM Kalle Valo wrote:
> Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>
> > On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote:
> >> Lauri Kasanen <cand-KK0ffGbhmjU@public.gmane.org> writes:
> >>
> >> > --- a/drivers/net/wireless/ath/carl9170/Kconfig
> >> > +++ b/drivers/net/wireless/ath/carl9170/Kconfig
> >> > @@ -5,12 +5,10 @@ config CARL9170
> >> > select FW_LOADER
> >> > select CRC32
> >> > help
> >> > - This is another driver for the Atheros "otus" 802.11n USB devices.
> >> > + This is the mainline driver for the Atheros "otus" 802.11n USB devices.
> >> >
> >> > - This driver provides more features than the original,
> >> > - but it needs a special firmware (carl9170-1.fw) to do that.
> >> > -
> >> > - The firmware can be downloaded from our wiki here:
> >> > + It needs a special firmware (carl9170-1.fw), which can be downloaded
> >> > + from our wiki here:
> >> > <http://wireless.kernel.org/en/users/Drivers/carl9170>
> >>
> >> Why even mention anything about a "special firmware" as the firmware is
> >> already available from linux-firmware.git?
> >
> > Yes and no. 1.9.6 is in linux-firmware.git. I've tried to add 1.9.9 too
> > but that failed.
> > <http://comments.gmane.org/gmane.linux.kernel.wireless.general/114639>
>
> Rick's comment makes sense to me, better just to provide the latest
> version. No need to unnecessary confuse the users. And if someone really
> wants to use an older version that she can retrieve it from the git
> history.
Part of the fun here is that firmware is GPLv2. The linux-firmware.git has
to point to or add the firmware source to their tree. They have added every
single source file to it.... instead of "packaging" it in a tar.bz2/gz/xz
like you normally do for release sources.
If you want to read more about it:
<http://www.spinics.net/lists/linux-wireless/msg101868.html>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] carl9170: Clarify kconfig text
From: Christian Lamparter @ 2016-04-18 17:10 UTC (permalink / raw)
To: Xose Vazquez Perez
Cc: Lauri Kasanen, Kalle Valo, LKML, linux-wireless, netdev,
Linux Firmware Maintainers, sgruszka
In-Reply-To: <c17f2f12-1c94-6b19-c918-0a6a9ee401ca@gmail.com>
On Monday, April 18, 2016 06:47:44 PM Xose Vazquez Perez wrote:
> Christian Lamparter wrote:
>
> > Sure, but this could be a different patch then. I think Intel devices
> > (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download
> > firmware from this device from our homepage here" too. So if we want,
> > we can remove them altogether?
>
> linux-firmware.git does not contain firmware for all drivers. _At least_
> zd1211rw [1], atmel [2] and ipw2x00 [3] are out of the tree.
Yeah, don't forget p54. It needs out-of-tree firmwares as well.
But what about iwlegacy? Isn't that another candidate that would fit both
requirements (no recent firmware update, firmware in linux-firmware.git) ?
> [1] http://sf.net/projects/zd1211/files/
> [2] http://web.archive.org/web/20121016132320/http://at76c503a.berlios.de/fw_dl.html
> [3] http://ipw2100.sf.net/firmware.php http://ipw2200.sf.net/firmware.php
^ permalink raw reply
* Re: switchdev fib offload issues
From: David Ahern @ 2016-04-18 17:11 UTC (permalink / raw)
To: Ilan Tayari, Jiri Pirko; +Cc: netdev@vger.kernel.org
In-Reply-To: <AM4PR0501MB19409325D618C1C2E9519E9FDB6B0@AM4PR0501MB1940.eurprd05.prod.outlook.com>
On 4/18/16 10:38 AM, Ilan Tayari wrote:
> Hi Jiri,
>
>> Thoughts?
>
> One general thought comes to mind, regardless of your proposed solutions:
>
> You'll need to take care to propagate the error properly in case of routes created by the kernel, such as local routes.
> Local routes are created when an IP address is added to an interface, so in such a case would the whole add-ip-address operation be rolled back cleanly?
local routes are added on an 'admin up' too which is completely
disconnected from adding the address to the interface.
^ permalink raw reply
* Re: switchdev fib offload issues
From: Hannes Frederic Sowa @ 2016-04-18 17:17 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, idosch, eladr, yotamg, ogerlitz, roopa, nikolay, jhs,
john.fastabend, rami.rosen, gospo, stephen, sfeldma, dsa,
f.fainelli, andrew, vivien.didelot, tgraf, aduyck
In-Reply-To: <20160418154757.GA2059@nanopsycho.amit.cz>
Hi Jiri,
On 18.04.2016 17:47, Jiri Pirko wrote:
> Proposed solutions (ideas):
> 1) per-netns. Add a procfs file:
> /proc/sys/net/ipv4/route/fib_offload_error_policy
> with values: "evict" - default, current behaviour
> "fail" - propagate offload error to user
> The policy value would be stored in struct net.
>
> 2) per-VRF/table
> When user creates a VRF master, he specifies a table ID
> this VRF is going to use. I propose to extend this so
> he can pass a policy ("evict"/"fail").
> The policy value would be stored in struct fib_table or
> struct fib6_table. The problem is that vfr only saves
> table ID, allocates dst but does not actually create
> table. That might be created later. But I think this
> could be resolved.
>
> 3) per-VFR/master_netdev
> In this case, the policy would be also set during
> the creation of VFR master. From user perspective,
> this looks same as 2)
> The policy value would be stored in struct net_vrf (vrf private).
I agree that a fail policy is probably the way forward regarding the
issues you outlined.
One question though:
Shouldn't the policy by an attribute of the switch, e.g. configurable by
devlink (maybe also not the right place)? Not sure how user space can
otherwise make correct assumptions about the state of the switch and
initiate proper countermeasures (e.g. reducing the smallest prefix
length installed to hardware).
Bye,
Hannes
^ permalink raw reply
* Re: [patch -next] udp: fix if statement in SIOCINQ ioctl
From: David Miller @ 2016-04-18 17:40 UTC (permalink / raw)
To: dan.carpenter
Cc: willemb, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20160418084449.GA12410@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 18 Apr 2016 11:44:49 +0300
> We deleted a line of code and accidentally made the "return put_user()"
> part of the if statement when it's supposed to be unconditional.
>
> Fixes: 9f9a45beaa96 ('udp: do not expect udp headers on ioctl SIOCINQ')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: rtnl_fill_stats: avoid an unnecssary stats copy
From: David Miller @ 2016-04-18 17:40 UTC (permalink / raw)
To: roopa; +Cc: netdev
In-Reply-To: <1460777785-43349-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Fri, 15 Apr 2016 20:36:25 -0700
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch passes netlink attr data ptr directly to dev_get_stats
> thus elimiating a stats copy.
>
> Suggested-by: David Miller <davem@davemloft.net>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Applied.
^ permalink raw reply
* [PATCH net-next 2/3] qede: Fix setting Skb network header
From: Manish Chopra @ 2016-04-18 17:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Yuval.Mintz
In-Reply-To: <1460999167-3746-1-git-send-email-manish.chopra@qlogic.com>
Skb's network header needs to be set before extracting IPv4/IPv6
headers from it.
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Yuval Mintz <yuval.mintz@qlogic.com>
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 4d76ac0..8208e1f 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -1068,7 +1068,6 @@ static void qede_gro_ip_csum(struct sk_buff *skb)
const struct iphdr *iph = ip_hdr(skb);
struct tcphdr *th;
- skb_set_network_header(skb, 0);
skb_set_transport_header(skb, sizeof(struct iphdr));
th = tcp_hdr(skb);
@@ -1083,7 +1082,6 @@ static void qede_gro_ipv6_csum(struct sk_buff *skb)
struct ipv6hdr *iph = ipv6_hdr(skb);
struct tcphdr *th;
- skb_set_network_header(skb, 0);
skb_set_transport_header(skb, sizeof(struct ipv6hdr));
th = tcp_hdr(skb);
@@ -1100,6 +1098,8 @@ static void qede_gro_receive(struct qede_dev *edev,
{
#ifdef CONFIG_INET
if (skb_shinfo(skb)->gso_size) {
+ skb_set_network_header(skb, 0);
+
switch (skb->protocol) {
case htons(ETH_P_IP):
qede_gro_ip_csum(skb);
--
2.7.2
^ permalink raw reply related
* [PATCH net-next 3/3] qede: Fix single MTU sized packet from firmware GRO flow
From: Manish Chopra @ 2016-04-18 17:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Yuval.Mintz
In-Reply-To: <1460999167-3746-1-git-send-email-manish.chopra@qlogic.com>
In firmware assisted GRO flow there could be a single MTU sized
segment arriving due to firmware aggregation timeout/last segment
in an aggregation flow, which is not expected to be an actual gro
packet. So If a skb has zero frags from the GRO flow then simply
push it in the stack as non gso skb.
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Yuval Mintz <yuval.mintz@qlogic.com>
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 8208e1f..197ef85 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -1096,6 +1096,17 @@ static void qede_gro_receive(struct qede_dev *edev,
struct sk_buff *skb,
u16 vlan_tag)
{
+ /* FW can send a single MTU sized packet from gro flow
+ * due to aggregation timeout/last segment etc. which
+ * is not expected to be a gro packet. If a skb has zero
+ * frags then simply push it in the stack as non gso skb.
+ */
+ if (unlikely(!skb->data_len)) {
+ skb_shinfo(skb)->gso_type = 0;
+ skb_shinfo(skb)->gso_size = 0;
+ goto send_skb;
+ }
+
#ifdef CONFIG_INET
if (skb_shinfo(skb)->gso_size) {
skb_set_network_header(skb, 0);
@@ -1114,6 +1125,8 @@ static void qede_gro_receive(struct qede_dev *edev,
}
}
#endif
+
+send_skb:
skb_record_rx_queue(skb, fp->rss_id);
qede_skb_receive(edev, fp, skb, vlan_tag);
}
--
2.7.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox