* 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: [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: [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: 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: 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: [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: [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: 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] 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: [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 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: 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 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: [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: [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 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
* [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 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
* 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: David Miller @ 2016-04-18 15:59 UTC (permalink / raw)
To: okaya-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
cov-sgV2jX0FEOL9JmXXK+q4OQ, yishaih-VPRAkNaXOzVWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87c17d3f979cf0167cd37077f39d0534-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
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.
--
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
* switchdev fib offload issues
From: Jiri Pirko @ 2016-04-18 15:47 UTC (permalink / raw)
To: 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
Hi all.
The current situation of fib offloading is not good, I believe we need
to make some changes, therefore I'm writing this email. Please read,
think and comment.
Currently what we have is that for every fib entry inserted into a table,
there is a call to switchdev:
fib_table_insert->switchdev_fib_ipv4_add
Driver then pushes fib entry down to HW. So far good.
However, if for any reason the switchdev add operation fails, there is an
abort function called (switchdev_fib_ipv4_abort). This function does two
things which are both unfortunate in many usecases:
1) evicts all fib entries from HW leaving all processing done in kernel
- For Spectrum ASIC this means that all traffic running at 100G between
all ports is immediately downgraded to ~1-3Gbits
- Also this happens silently, user knows nothing about anything went wrong,
only forwarding performance suddenly sucks.
2) sets net->ipv4.fib_offload_disabled = true
- That results in no other fib entry being offloaded, forever,
until net is removed and added again, machine reboot is required
in case if init_ns
These 2 issues makes fib offload completely unusable. So I propose
to start thinking about fixing this.
I believe that although the current behaviour might be good for default,
user should be able to change it by setting a different policy. This
policy will allow to propagate offload error to user.
Note that user already has to handle fib add errors which are independent
on particular fib entry. That is a case of insufficient memory (-ENOBUFS).
In fact, when offload fails, that is most likely also due to insufficient
resources in HW.
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).
Thoughts?
Thanks!
Jiri
^ permalink raw reply
* Re: [PATCH v2] carl9170: Clarify kconfig text
From: Kalle Valo @ 2016-04-18 15:45 UTC (permalink / raw)
To: Lauri Kasanen
Cc: Christian Lamparter, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160416171856.1769c0e16bcc75372407e06f-KK0ffGbhmjU@public.gmane.org>
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? 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?
--
Kalle Valo
--
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] net: ethernet: mellanox: correct page conversion
From: Christoph Hellwig @ 2016-04-18 15:40 UTC (permalink / raw)
To: Sinan Kaya
Cc: Christoph Hellwig, Eli Cohen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Yishai Hadas,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5714FB68.3020604-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Mon, Apr 18, 2016 at 11:21:12AM -0400, Sinan Kaya wrote:
> I was looking at the code. I don't see how removing virt_to_page + vmap
> would solve the issue.
>
> The code is trying to access the buffer space with direct.buf member
> from the CPU side. This member would become NULL, when this code is
> removed and also in mlx4_en_map_buffer.
>
> ...
>
> What am I missing?
As mentioned before you'll also need to enforce you hit the nbufs = 1
case for these. In fact most callers should simply switch to a plain
dma_zalloc_coherent call without all these wrappers. If we have a case
where we really want multiple buffers that don't have to be contiguous
(maybe the MTT case) I'd rather opencode that instead of building this
confusing interface on top of it.
--
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] net: ipv6: Do not fix up linklocal and loopback addresses
From: Mike Manning @ 2016-04-18 15:28 UTC (permalink / raw)
To: netdev
In-Reply-To: <5714EDDB.8080306@brocade.com>
f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") added
the option to retain user configured addresses on an admin down. A comment
to one of the later revisions suggested using the IFA_F_PERMANENT flag rather
than adding a user_managed boolean to the ifaddr struct. A side effect of
this change is that link local and loopback addresses were also retained which
was not part of the objective of the original changes. The fix 70af921db6f8
("net: ipv6: Do not keep linklocal and loopback addresses") ensures that these
are no longer kept. Similarly, the present fix ensures that these addresses
are not fixed up, otherwise the incorrect fixup triggers a crash in fib6.
Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning <mmanning@brocade.com>
---
net/ipv6/addrconf.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 23cec53..cba4e10 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3200,6 +3200,12 @@ static void l3mdev_check_host_rt(struct inet6_dev *idev,
}
#endif
+static bool addr_is_local(const struct in6_addr *addr)
+{
+ return ipv6_addr_type(addr) &
+ (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
+}
+
static int fixup_permanent_addr(struct inet6_dev *idev,
struct inet6_ifaddr *ifp)
{
@@ -3238,6 +3244,7 @@ static void addrconf_permanent_addr(struct net_device *dev)
list_for_each_entry_safe(ifp, tmp, &idev->addr_list, if_list) {
if ((ifp->flags & IFA_F_PERMANENT) &&
+ !addr_is_local(&ifp->addr) &&
fixup_permanent_addr(idev, ifp) < 0) {
write_unlock_bh(&idev->lock);
ipv6_del_addr(ifp);
@@ -3448,12 +3455,6 @@ static void addrconf_type_change(struct net_device *dev, unsigned long event)
ipv6_mc_unmap(idev);
}
-static bool addr_is_local(const struct in6_addr *addr)
-{
- return ipv6_addr_type(addr) &
- (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
-}
-
static int addrconf_ifdown(struct net_device *dev, int how)
{
struct net *net = dev_net(dev);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Sinan Kaya @ 2016-04-18 15:22 UTC (permalink / raw)
To: Timur Tabi, Christoph Hellwig
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, cov-sgV2jX0FEOL9JmXXK+q4OQ,
Yishai Hadas, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5714FA2C.4030209-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 4/18/2016 11:15 AM, Timur Tabi wrote:
> Sinan Kaya wrote:
>>
>> VMAP allows you to make several pages look contiguous to the CPU.
>> It can only be used against logical addresses returned from kmalloc
>> or alloc_page.
>>
>> You cannot take several virtually mapped addresses returned by dma_alloc_coherent
>> and try to make them virtually contiguous again.
>>
>> The code happens to work on other architectures by pure luck. AFAIK, dma_alloc_coherent
>> returns logical addresses on Intel systems until it runs out of DMA memory. After
>> that intel arch will also start returning virtually mapped addresses and this code
>> will also fail. ARM64 on the other hand always returns a virtually mapped address.
>>
>> The goal of this code is to allocate a bunch of page sized memory and make it look
>> contiguous. It is just using the wrong API. The correct API is either kmalloc or
>> alloc_page map it with dma_map_page not dma_alloc_coherent.
>>
>> The proper usage of dma_map_page requires code to call dma_sync API in correct
>> places to be compatible with noncoherent systems. This code is already assuming
>> coherency. It would be a nice to have dma_sync APIs in right places. There is no
>> harm in calling dma_sync API for coherent systems as they are no-ops in DMA mapping
>> layer whereas it is a cache flush for non-coherent systems.
>
> The text would be a great addition to the patch description.
>
I can do that on the next version.
--
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
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