* [PATCH net-next] mlx4: fix mlx4_en_set_rxfh()
From: Eric Dumazet @ 2014-11-23 1:24 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David S. Miller, netdev, Amir Vadai
In-Reply-To: <1416700690.20938.34.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
mlx4_en_set_rxfh() can crash if no RSS indir table is provided.
While we are at it, allow RSS key to be changed with ethtool -X
Tested:
myhost:~# cat /proc/sys/net/core/netdev_rss_key
b6:89:91:f3:b2:c3:c2:90:11:e8:ce:45:e8:a9:9d:1c:f2:f6:d4:53:61:8b:26:3a:b3:9a:57:97:c3:b6:79:4d:2e:d9:66:5c:72:ed:b6:8e:c5:5d:4d:8c:22:67:30:ab:8a:6e:c3:6a
myhost:~# ethtool -x eth0
RX flow hash indirection table for eth0 with 8 RX ring(s):
0: 0 1 2 3 4 5 6 7
RSS hash key:
b6:89:91:f3:b2:c3:c2:90:11:e8:ce:45:e8:a9:9d:1c:f2:f6:d4:53:61:8b:26:3a:b3:9a:57:97:c3:b6:79:4d:2e:d9:66:5c:72:ed:b6:8e
myhost:~# ethtool -X eth0 hkey \
03:0e:e2:43:fa:82:0e:73:14:2d:c0:68:21:9e:82:99:b9:84:d0:22:e2:b3:64:9f:4a:af:00:fa:cc:05:b4:4a:17:05:14:73:76:58:bd:2f
myhost:~# ethtool -x eth0
RX flow hash indirection table for eth0 with 8 RX ring(s):
0: 0 1 2 3 4 5 6 7
RSS hash key:
03:0e:e2:43:fa:82:0e:73:14:2d:c0:68:21:9e:82:99:b9:84:d0:22:e2:b3:64:9f:4a:af:00:fa:cc:05:b4:4a:17:05:14:73:76:58:bd:2f
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: b9d1ab7eb42e ("mlx4: use netdev_rss_key_fill() helper")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 10 +++++++---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 +--
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 +
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index bdff834a2a7e..c45e06abc073 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -994,7 +994,7 @@ static int mlx4_en_get_rxfh(struct net_device *dev, u32 *ring_index, u8 *key)
rss_map->base_qpn;
}
if (key)
- netdev_rss_key_fill(key, MLX4_EN_RSS_KEY_SIZE);
+ memcpy(key, priv->rss_key, MLX4_EN_RSS_KEY_SIZE);
return err;
}
@@ -1012,6 +1012,8 @@ static int mlx4_en_set_rxfh(struct net_device *dev, const u32 *ring_index,
* between rings
*/
for (i = 0; i < priv->rx_ring_num; i++) {
+ if (!ring_index)
+ continue;
if (i > 0 && !ring_index[i] && !rss_rings)
rss_rings = i;
@@ -1032,8 +1034,10 @@ static int mlx4_en_set_rxfh(struct net_device *dev, const u32 *ring_index,
mlx4_en_stop_port(dev, 1);
}
- priv->prof->rss_rings = rss_rings;
-
+ if (ring_index)
+ priv->prof->rss_rings = rss_rings;
+ if (key)
+ memcpy(priv->rss_key, key, MLX4_EN_RSS_KEY_SIZE);
if (port_up) {
err = mlx4_en_start_port(dev);
if (err)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 89440cb25ad8..b7c99780aef3 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2493,6 +2493,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
priv->num_tx_rings_p_up = mdev->profile.num_tx_rings_p_up;
priv->tx_ring_num = prof->tx_ring_num;
priv->tx_work_limit = MLX4_EN_DEFAULT_TX_WORK;
+ netdev_rss_key_fill(priv->rss_key, sizeof(priv->rss_key));
priv->tx_ring = kzalloc(sizeof(struct mlx4_en_tx_ring *) * MAX_TX_RINGS,
GFP_KERNEL);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index b7bda8956011..946d35280abc 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1223,8 +1223,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
rss_context->flags = rss_mask;
rss_context->hash_fn = MLX4_RSS_HASH_TOP;
- netdev_rss_key_fill(rss_context->rss_key, MLX4_EN_RSS_KEY_SIZE);
-
+ memcpy(rss_context->rss_key, priv->rss_key, MLX4_EN_RSS_KEY_SIZE);
err = mlx4_qp_to_ready(mdev->dev, &priv->res.mtt, &context,
&rss_map->indir_qp, &rss_map->indir_state);
if (err)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index de456749ffae..aaa7efbb9664 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -618,6 +618,7 @@ struct mlx4_en_priv {
__be16 vxlan_port;
u32 pflags;
+ u8 rss_key[MLX4_EN_RSS_KEY_SIZE];
};
enum mlx4_en_wol {
^ permalink raw reply related
* Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"
From: Eric Dumazet @ 2014-11-23 1:27 UTC (permalink / raw)
To: SF Markus Elfring
Cc: netdev, Haiyang Zhang, kernel-janitors, linux-kernel,
Julia Lawall, devel, David Miller
In-Reply-To: <54712F8C.10206@users.sourceforge.net>
On Sun, 2014-11-23 at 01:51 +0100, SF Markus Elfring wrote:
> > This has nothing to do with me asking you to frame your patches
> > against the correct tree.
>
> I imagine than someone other can also pick up this update suggestion
> (a simple change of two lines) quicker before I might try another
> software build again from a different commit as a base.
I have no idea why someone would do that.
If you don't bother resubmit, nobody will.
^ permalink raw reply
* Low Interest Rate!
From: Ocean Finance And Bussiness Co @ 2014-11-22 19:36 UTC (permalink / raw)
To: Recipients
Do You Need A Loan?Apply Now For More Details.
^ permalink raw reply
* Re: [PATCH 1/2] 8139too: Allow setting MTU larger than 1500
From: Ben Hutchings @ 2014-11-23 2:42 UTC (permalink / raw)
To: Alban
Cc: linux-kernel, netdev, Bjorn Helgaas, Benoit Taine,
Eric W. Biederman, David S. Miller
In-Reply-To: <20141121195738.038d2cc2@tock>
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]
On Fri, 2014-11-21 at 19:57 +0100, Alban wrote:
> On Fri, 21 Nov 2014 18:51:51 +0000
> Ben Hutchings <ben@decadent.org.uk> wrote:
>
> > On Fri, 2014-11-21 at 14:58 +0100, Alban wrote:
> > > On Fri, 21 Nov 2014 00:34:34 +0000
> > > Ben Hutchings <ben@decadent.org.uk> wrote:
> > >
> > > > On Sat, 2014-11-08 at 12:48 +0100, Alban Bedel wrote:
> > > > > Replace the default ndo_change_mtu callback with one that allow
> > > > > setting MTU that the driver can handle.
> > > > >
> > > > > Signed-off-by: Alban Bedel <albeu@free.fr>
> > > > > ---
> > > > > drivers/net/ethernet/realtek/8139too.c | 13 ++++++++++++-
> > > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/net/ethernet/realtek/8139too.c
> > > > > b/drivers/net/ethernet/realtek/8139too.c index 007b38c..8387de9
> > > > > 100644 --- a/drivers/net/ethernet/realtek/8139too.c
> > > > > +++ b/drivers/net/ethernet/realtek/8139too.c
> > > > > @@ -185,6 +185,9 @@ static int debug = -1;
> > > > > /* max supported ethernet frame size -- must be at least
> > > > > (dev->mtu+14+4).*/ #define MAX_ETH_FRAME_SIZE 1536
> > > > >
> > > > > +/* max supported payload size */
> > > > > +#define MAX_ETH_DATA_SIZE (MAX_ETH_FRAME_SIZE -
> > > > > ETH_HLEN - ETH_FCS_LEN)
> > > > [...]
> > > >
> > > > Does this maximum still allow for VLAN tags, or should it use
> > > > VLAN_ETH_HLEN instead of ETH_HLEN?
> > >
> > > That might well be as the VLAN code seems to assume that the
> > > physical device can handle frames of MTU + VLAN_HLEN bytes. I can
> > > fix it, but to me it seems like the VLAN code should be fixed to
> > > respect the physical device MTU.
> >
> > Drivers that support VLANs have to allow for at least one VLAN tag
> > when validating the MTU. This is obviously broken for multiple
> > layers of VLAN tags, but those are the semantics we're stuck with.
>
> Ok, I see. Should a I send a fix patch or redo a new version of this
> patch?
As your previous patches have already been applied, you'll need to send
a fix patch (if the answer to my question was no).
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real device.
From: Ben Hutchings @ 2014-11-23 3:15 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Stefan Sørensen
In-Reply-To: <1416575780-19132-1-git-send-email-richardcochran@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
On Fri, 2014-11-21 at 14:16 +0100, Richard Cochran wrote:
> Commit a6111d3c "vlan: Pass SIOC[SG]HWTSTAMP ioctls to real device"
> intended to enable hardware time stamping on VLAN interfaces, but
> passing SIOCSHWTSTAMP is only half of the story. This patch adds
> the second half, by letting user space find out the time stamping
> capabilities of the device backing a VLAN interface.
[...]
This assumes that the same PTP capabilities apply to VLAN-tagged frames.
I don't think it's at all safe to assume that RX filter modes other than
HWTSTAMP_FILTER_ALL will include VLAN-tagged frames. I think it is
necessary to define additional modes that explicitly include VLAN-tagged
frames.
I also disagree in general that reconfiguring a VLAN device should make
changes to the underlying device that affect more than just that VLAN,
i.e. SIOCSHWTSTAMP should not be passed through. SIOCGHWTSTAMP could be
passed through, but rx_filter would need adjustment (VLAN-tagged modes
on the underlying devices become untagged modes on the VLAN device).
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Potential bugs found in ne2k-pci+8390
From: Ben Hutchings @ 2014-11-23 3:21 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: netdev
In-Reply-To: <000001d00607$90e5ee70$b2b1cb50$@163.com>
[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]
On Sat, 2014-11-22 at 11:51 +0800, Jia-Ju Bai wrote:
> Dear Sir,
> I'm very sorry to trouble you.
> Recently I test 15 linux device drivers and find some potential bugs both in
> Linux 3.8.6 and Linux 3.17.2.
>
> The target file is drivers/net/ethernet/8390/ne2k-pci.c, which is used to
> build ne2k-pci.ko. I hope you can help me check my findings:
> [1] The function request_region is called by ne2k_pci_init_one when
> initializing the ethernet card driver. But when request_region is failed,
> which means that it returns the error value, ne2k_pci_init_one returns
> immediately to halt the process. However, because pci_enable_device has been
> called before request_region in ne2k_pci_init_one, pci_disable_device should
> be called before exiting. When the driver works normally, pci_enable_device
> and pci_disable_device are called in pairs in ne2k_pci_init_one and
> ne2k_pci_remove_one. Moreover, other ethernet card drivers call
> pci_enable_device and pci_disable_device in pairs in error handling paths,
> such as r8169 and sky2.
> [2] The similar problem to [1] occurs when alloc_ei_netdev is failed in
> ne2k_pci_init_one.
> [3] The similar problem to [1] occurs when register_netdev is failed in
> ne2k_pci_init_one.
>
> Could you help me check these findings? Thank you very much, and I'm looking
> forward to your reply.
I agree this is a real bug (or bugs). You should send a patch to fix
this - see Documentation/SubmittingPatches.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [net-next 13/17] i40evf: refactor ethtool RSS handling
From: Ben Hutchings @ 2014-11-23 3:44 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Mitch Williams, netdev, nhorman, sassmann, jogreene
In-Reply-To: <1416635708-4765-15-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
On Fri, 2014-11-21 at 21:55 -0800, Jeff Kirsher wrote:
> From: Mitch Williams <mitch.a.williams@intel.com>
>
> Add support for setting the RSS key as it is now implemented.
>
> Change-ID: I9290ae3ea99d0e46053540650f95e24a24e453f1
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> Tested-by: Jim Young <jamesx.m.young@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 66 ++++++++++++++++------
> 1 file changed, 50 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
> index 69a269b..ed0e4dc 100644
> --- a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
> @@ -608,6 +608,19 @@ static void i40evf_get_channels(struct net_device *netdev,
> ch->combined_count = adapter->num_active_queues;
> }
>
> +#define I40EVF_HLUT_ARRAY_SIZE ((I40E_VFQF_HLUT_MAX_INDEX + 1) * 4)
> +#define I40EVF_HKEY_ARRAY_SIZE ((I40E_VFQF_HKEY_MAX_INDEX * 1) * 4)
The '* 1' should be '+ 1' as on the previous line?
[...]
> @@ -631,19 +644,28 @@ static int i40evf_get_rxfh(struct net_device *netdev, u32 *indir, u8 *key)
> {
> struct i40evf_adapter *adapter = netdev_priv(netdev);
> struct i40e_hw *hw = &adapter->hw;
> - u32 hlut_val;
> + u32 reg_val;
> int i, j;
> for (i = 0, j = 0; i <= I40E_VFQF_HLUT_MAX_INDEX; i++) {
> - hlut_val = rd32(hw, I40E_VFQF_HLUT(i));
> - indir[j++] = hlut_val & 0xff;
> - indir[j++] = (hlut_val >> 8) & 0xff;
> - indir[j++] = (hlut_val >> 16) & 0xff;
> - indir[j++] = (hlut_val >> 24) & 0xff;
> + reg_val = rd32(hw, I40E_VFQF_HLUT(i));
> + indir[j++] = reg_val & 0xff;
> + indir[j++] = (reg_val >> 8) & 0xff;
> + indir[j++] = (reg_val >> 16) & 0xff;
> + indir[j++] = (reg_val >> 24) & 0xff;
> + }
You need an 'if (indir)' around that block now.
> + if (key) {
> + for (i = 0, j = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++) {
> + reg_val = rd32(hw, I40E_VFQF_HKEY(i));
> + key[j++] = (u8)(reg_val & 0xff);
> + key[j++] = (u8)((reg_val >> 8) & 0xff);
> + key[j++] = (u8)((reg_val >> 16) & 0xff);
> + key[j++] = (u8)((reg_val >> 24) & 0xff);
> + }
> }
> return 0;
> }
> -
You should keep the blank line between functions.
[...]
> @@ -687,10 +719,12 @@ static const struct ethtool_ops i40evf_ethtool_ops = {
> .set_coalesce = i40evf_set_coalesce,
> .get_rxnfc = i40evf_get_rxnfc,
> .set_rxnfc = i40evf_set_rxnfc,
> + .get_rxfh_key_size = i40evf_get_rxfh_key_size,
> .get_rxfh_indir_size = i40evf_get_rxfh_indir_size,
> .get_rxfh = i40evf_get_rxfh,
> .set_rxfh = i40evf_set_rxfh,
> .get_channels = i40evf_get_channels,
> +
But you don't need a blank line here.
Ben.
> };
>
> /**
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [net-next 14/17] i40e: implement ethtool RSS config
From: Ben Hutchings @ 2014-11-23 3:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jeff Kirsher, davem, Mitch Williams, netdev, nhorman, sassmann,
jogreene
In-Reply-To: <1416680547.20938.20.camel@edumazet-glaptop2.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
On Sat, 2014-11-22 at 10:22 -0800, Eric Dumazet wrote:
> On Fri, 2014-11-21 at 21:55 -0800, Jeff Kirsher wrote:
[...]
> > +static int i40e_set_rxfh(struct net_device *netdev, const u32 *indir,
> > + const u8 *key)
> > +{
> > + struct i40e_netdev_priv *np = netdev_priv(netdev);
> > + struct i40e_vsi *vsi = np->vsi;
> > + struct i40e_pf *pf = vsi->back;
> > + struct i40e_hw *hw = &pf->hw;
> > + u32 reg_val;
> > + int i, j;
> > +
> > + if (indir) {
> > + for (i = 0, j = 0; i <= I40E_PFQF_HLUT_MAX_INDEX; i++) {
> > + reg_val = indir[j++];
>
> Shouldn't you check the indir[X] values are in correct range ?
>
> ( seems to be between 0 and [pf->rss_size_max - 1] )
[...]
The caller guarantees to do that.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [net-next 14/17] i40e: implement ethtool RSS config
From: Ben Hutchings @ 2014-11-23 3:53 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Mitch Williams, netdev, nhorman, sassmann, jogreene
In-Reply-To: <1416635708-4765-16-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On Fri, 2014-11-21 at 21:55 -0800, Jeff Kirsher wrote:
> From: Mitch Williams <mitch.a.williams@intel.com>
>
> Support ethtool methods for getting and setting the RSS look-up table.
>
> Change-ID: I52707fb371fc11fe9fd4c287e08542cde38f79d4
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> Tested-by: Jim Young <jamesx.m.young@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 104 +++++++++++++++++++++++++
> 1 file changed, 104 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> index fcd815d..f9f68ea 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> @@ -2237,6 +2237,106 @@ static int i40e_set_channels(struct net_device *dev,
> return -EINVAL;
> }
>
> +#define I40E_HLUT_ARRAY_SIZE ((I40E_PFQF_HLUT_MAX_INDEX + 1) * 4)
> +#define I40E_HKEY_ARRAY_SIZE ((I40E_PFQF_HKEY_MAX_INDEX * 1) * 4)
Same typo as in i40evf.
[...]
> +static int i40e_get_rxfh(struct net_device *netdev, u32 *indir, u8 *key)
> +{
> + struct i40e_netdev_priv *np = netdev_priv(netdev);
> + struct i40e_vsi *vsi = np->vsi;
> + struct i40e_pf *pf = vsi->back;
> + struct i40e_hw *hw = &pf->hw;
> + u32 reg_val;
> + int i, j;
> +
> + for (i = 0, j = 0; i <= I40E_PFQF_HLUT_MAX_INDEX; i++) {
> + reg_val = rd32(hw, I40E_PFQF_HLUT(i));
> + indir[j++] = reg_val & 0xff;
> + indir[j++] = (reg_val >> 8) & 0xff;
> + indir[j++] = (reg_val >> 16) & 0xff;
> + indir[j++] = (reg_val >> 24) & 0xff;
> + }
[...]
Same missing condition as in i40evf.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 12/14] mlx4: use netdev_rss_key_fill() helper
From: Ben Hutchings @ 2014-11-23 4:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, David S. Miller, netdev, Thomas Lendacky,
Ariel Elior, Michael Chan, Prashant Sreedharan, Rasesh Mody,
Sathya Perla, Subbu Seetharaman, Ajit Khaparde, Jesse Brandeburg,
Jeff Kirsher, Amir Vadai, Shradha Shah, Shreyas Bhatewara
In-Reply-To: <1416700690.20938.34.camel@edumazet-glaptop2.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Sat, 2014-11-22 at 15:58 -0800, Eric Dumazet wrote:
> On Sat, 2014-11-22 at 21:49 +0000, Ben Hutchings wrote:
> > On Sun, 2014-11-16 at 06:23 -0800, Eric Dumazet wrote:
> > > Use of well known RSS key increases attack surface.
> > > Switch to a random one, using generic helper so that all
> > > ports share a common key.
> > >
> > > Also provide ethtool -x support to fetch RSS key
> > [...]
> > > @@ -1799,6 +1805,7 @@ const struct ethtool_ops mlx4_en_ethtool_ops = {
> > > .get_rxnfc = mlx4_en_get_rxnfc,
> > > .set_rxnfc = mlx4_en_set_rxnfc,
> > > .get_rxfh_indir_size = mlx4_en_get_rxfh_indir_size,
> > > + .get_rxfh_key_size = mlx4_en_get_rxfh_key_size,
> > > .get_rxfh = mlx4_en_get_rxfh,
> > > .set_rxfh = mlx4_en_set_rxfh,
> > [...]
> >
> > A driver that implements get_rxfh_key_size() and set_rxfh() is assumed
> > to support setting the RSS key (and only the key). However,
> > mlx4_en_set_rxfh() will currently crash if a new indirection table is
> > not provided.
>
> Hi Ben.
>
> Is this a net-next only concern, or is it an existing problem in net
> tree ?
It's introduced by the above patch, as you seem to have worked out.
Drivers not implementing ethtool_ops::get_rxfh_key_size will always get
a non-null indir pointer (see commit 61d88c6811f2).
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 12/14] mlx4: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-23 4:14 UTC (permalink / raw)
To: Ben Hutchings
Cc: Eric Dumazet, David S. Miller, netdev, Thomas Lendacky,
Ariel Elior, Michael Chan, Prashant Sreedharan, Rasesh Mody,
Sathya Perla, Subbu Seetharaman, Ajit Khaparde, Jesse Brandeburg,
Jeff Kirsher, Amir Vadai, Shradha Shah, Shreyas Bhatewara
In-Reply-To: <1416715651.7215.43.camel@decadent.org.uk>
On Sun, 2014-11-23 at 04:07 +0000, Ben Hutchings wrote:
> It's introduced by the above patch, as you seem to have worked out.
> Drivers not implementing ethtool_ops::get_rxfh_key_size will always get
> a non-null indir pointer (see commit 61d88c6811f2).
Yep, thanks Ben ;)
^ permalink raw reply
* Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"
From: David Miller @ 2014-11-23 4:36 UTC (permalink / raw)
To: elfring
Cc: haiyangz, kys, devel, netdev, linux-kernel, kernel-janitors,
julia.lawall
In-Reply-To: <54712F8C.10206@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 23 Nov 2014 01:51:24 +0100
>> This has nothing to do with me asking you to frame your patches
>> against the correct tree.
>
> I imagine than someone other can also pick up this update suggestion
> (a simple change of two lines) quicker before I might try another
> software build again from a different commit as a base.
Whereas if you learn how to base your changes cleanly on the correct
base now, all of your future submissions will go quickly and smoothly
into my tree.
^ permalink raw reply
* FIX ME in e1000_82575.c
From: nick @ 2014-11-23 4:42 UTC (permalink / raw)
To: jeffrey.t.kirsher@intel.com >> Jeff Kirsher
Cc: linux.nics, e1000-devel, bruce.w.allan, jesse.brandeburg, netdev,
linux-kernel
Greetings Again Jeff,
I am wondering about sending in a patch to FIX ME in the file, e1000_82575 due to incorrect values in the function,
igdb_acquire_swfw_sync_82575. If you or one of the other maintainers at Intel can send me the correct values or a hardware reference for me to find the values, I would be glad to send it a patch fixing these outstanding issues.
Regards Nick
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-net 0/4] Increase the limit of tuntap queues
From: Pankaj Gupta @ 2014-11-23 5:22 UTC (permalink / raw)
To: Michael S. Tsirkin, David Miller
Cc: linux-kernel, netdev, jasowang, dgibson, vfalico, edumazet,
vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings, xii, stephen,
jiri, sergei shtylyov
In-Reply-To: <20141119204427.GB30994@redhat.com>
> On Wed, Nov 19, 2014 at 03:16:28PM -0500, David Miller wrote:
> > From: Pankaj Gupta <pagupta@redhat.com>
> > Date: Tue, 18 Nov 2014 21:52:54 +0530
> >
> > > - Accept maximum number of queues as sysctl param so that any user space
> > > application like libvirt can use this value to limit number of queues.
> > > Also
> > > Administrators can specify maximum number of queues by updating this
> > > sysctl
> > > entry.
> >
> > This is the only part I don't like.
> >
> > Just let whoever has privileges to configure the tun device shoot
> > themselves in the foot if they want to by configuring "too many"
> > queues.
> >
> > If the virtual entity runs itself out of resources by doing something
> > stupid, it's purely their problem.
We can configure some fixed number of queues like 16 or so at the start
if multiqueue is enabled and then if somebody needs more then that, they
can do on their own.
If we dont want anyone to directly increase the number of queues, we can add
an ioctl command for increasing number of queues?
Suggestions here.
>
> Well it will run host out of kernel, no?
>
> --
> MST
>
^ permalink raw reply
* Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"
From: SF Markus Elfring @ 2014-11-23 7:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Haiyang Zhang, kernel-janitors, linux-kernel,
Julia Lawall, devel, David Miller
In-Reply-To: <1416706034.17888.9.camel@edumazet-glaptop2.roam.corp.google.com>
>> I imagine than someone other can also pick up this update suggestion
>> (a simple change of two lines) quicker before I might try another
>> software build again from a different commit as a base.
>
> I have no idea why someone would do that.
I imagine that other software users (besides me) like developers
and testers might also become curious to try the proposed changes out.
How much will they eventually help to run Linux components a bit faster?
> If you don't bother resubmit, nobody will.
I hope that there are more possibilities for anticipation and acceptance
of source code improvement potentials.
Would you also like to contribute a bit more fine-tuning for the affected
software versions?
Regards,
Markus
^ permalink raw reply
* [PATCH] ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic
From: Xin Long @ 2014-11-23 7:04 UTC (permalink / raw)
To: network dev, Steffen Klassert; +Cc: Xin Long, Cong Wang
Now the vti_link_ops do not point the .dellink, for fb tunnel device
(ip_vti0), the net_device will be removed as the default .dellink is
unregister_netdevice_queue,but the tunnel still in the tunnel list,
then if we add a new vti tunnel, in ip_tunnel_find():
hlist_for_each_entry_rcu(t, head, hash_node) {
if (local == t->parms.iph.saddr &&
remote == t->parms.iph.daddr &&
link == t->parms.link &&
==> type == t->dev->type &&
ip_tunnel_key_match(&t->parms, flags, key))
break;
}
the panic will happen, cause dev of ip_tunnel *t is null:
[ 3835.072977] IP: [<ffffffffa04103fd>] ip_tunnel_find+0x9d/0xc0 [ip_tunnel]
[ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0
[ 3835.073008] Oops: 0000 [#1] SMP
.....
[ 3835.073008] Stack:
[ 3835.073008] ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0
[ 3835.073008] ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858
[ 3835.073008] ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000
[ 3835.073008] Call Trace:
[ 3835.073008] [<ffffffffa0411924>] ip_tunnel_newlink+0x64/0x160 [ip_tunnel]
[ 3835.073008] [<ffffffffa040b2e3>] vti_newlink+0x43/0x70 [ip_vti]
[ 3835.073008] [<ffffffff8150d4da>] rtnl_newlink+0x4fa/0x5f0
[ 3835.073008] [<ffffffff812f68bb>] ? nla_strlcpy+0x5b/0x70
[ 3835.073008] [<ffffffff81508fb0>] ? rtnl_link_ops_get+0x40/0x60
[ 3835.073008] [<ffffffff8150d11f>] ? rtnl_newlink+0x13f/0x5f0
[ 3835.073008] [<ffffffff81509cf4>] rtnetlink_rcv_msg+0xa4/0x270
[ 3835.073008] [<ffffffff8126adf5>] ? sock_has_perm+0x75/0x90
[ 3835.073008] [<ffffffff81509c50>] ? rtnetlink_rcv+0x30/0x30
[ 3835.073008] [<ffffffff81529e39>] netlink_rcv_skb+0xa9/0xc0
[ 3835.073008] [<ffffffff81509c48>] rtnetlink_rcv+0x28/0x30
....
modprobe ip_vti
ip link del ip_vti0 type vti
ip link add ip_vti0 type vti
rmmod ip_vti
do that one or more times, kernel will panic.
fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in
which we skip the unregister of fb tunnel device. do the same on ip6_vti.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
---
net/ipv4/ip_vti.c | 1 +
net/ipv6/ip6_vti.c | 11 +++++++++++
2 files changed, 12 insertions(+)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 3e86101..1a7e979 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -528,6 +528,7 @@ static struct rtnl_link_ops vti_link_ops __read_mostly = {
.validate = vti_tunnel_validate,
.newlink = vti_newlink,
.changelink = vti_changelink,
+ .dellink = ip_tunnel_dellink,
.get_size = vti_get_size,
.fill_info = vti_fill_info,
};
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 31089d1..bcda14d 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -905,6 +905,15 @@ static int vti6_newlink(struct net *src_net, struct net_device *dev,
return vti6_tnl_create2(dev);
}
+static void vti6_dellink(struct net_device *dev, struct list_head *head)
+{
+ struct net *net = dev_net(dev);
+ struct vti6_net *ip6n = net_generic(net, vti6_net_id);
+
+ if (dev != ip6n->fb_tnl_dev)
+ unregister_netdevice_queue(dev, head);
+}
+
static int vti6_changelink(struct net_device *dev, struct nlattr *tb[],
struct nlattr *data[])
{
@@ -980,6 +989,7 @@ static struct rtnl_link_ops vti6_link_ops __read_mostly = {
.setup = vti6_dev_setup,
.validate = vti6_validate,
.newlink = vti6_newlink,
+ .dellink = vti6_dellink,
.changelink = vti6_changelink,
.get_size = vti6_get_size,
.fill_info = vti6_fill_info,
@@ -1020,6 +1030,7 @@ static int __net_init vti6_init_net(struct net *net)
if (!ip6n->fb_tnl_dev)
goto err_alloc_dev;
dev_net_set(ip6n->fb_tnl_dev, net);
+ ip6n->fb_tnl_dev->rtnl_link_ops = &vti6_link_ops;
err = vti6_fb_tnl_dev_init(ip6n->fb_tnl_dev);
if (err < 0)
--
1.8.3.1
^ permalink raw reply related
* Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"
From: SF Markus Elfring @ 2014-11-23 7:18 UTC (permalink / raw)
To: David Miller
Cc: Haiyang Zhang, K. Y. Srinivasan, devel, netdev, linux-kernel,
kernel-janitors, Julia Lawall
In-Reply-To: <20141122.233654.279540319568229037.davem@davemloft.net>
> Whereas if you learn how to base your changes cleanly on the correct
> base now, all of your future submissions will go quickly and smoothly
> into my tree.
My reluctance to work with more Linux repositories will evolve
over time. The faster affected software versions can be rebuilt
the more it will become interesting to try even more source
code improvements out, won't it?
I find it nice that you could accept update suggestions for
a few other Linux components already.
Regards,
Markus
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-11-23 9:43 UTC (permalink / raw)
To: Michael Tokarev
Cc: Maximilian Engelhardt, Rafał Miłecki, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <546D04EE.1030200@msgid.tls.msk.ru>
[-- Attachment #1: Type: text/plain, Size: 3741 bytes --]
On 19-11-14 22:00, Michael Tokarev wrote:
> 19.11.2014 22:58, Michael Tokarev wrote:
>> 19.11.2014 20:54, Arend van Spriel wrote:
> []
>>> I submitted two patches upstream and additionally I have attached two other that are still under review. Could you try these patches and sent me the content of the two debugfs files 'macstat' and 'hardware' after a stall has occurred.
>>
>> You didn't tell which kernel it is based on. So I tried it on 3.16,
>
> Ok, I misunderstood you apparently, -- I only tried 2 patches,
> while I should try all 4. So here it goes.
>
> The hardware info again:
>
>> chipnum 0x4313
>> chiprev 0x1
>> chippackage 0x8
>> corerev 0x18
>> boardid 0x1795
>> boardvendor 0x103c
>> boardrev P107
>> boardflags 0x402201
>> boardflags2 0x884
>> ucoderev 0x262032c
>> radiorev 0x1
>> phytype 0x8
>> phyrev 0x1
>> anarev 0xa
>> nvramrev 8
>
> Macstat:
>
> txallfrm: 287
> txrtsfrm: 118
> txctsfrm: 25
> txackfrm: 60
> txdnlfrm: 0
> txbcnfrm: 0
> txfunfl[8]: 0 0 0 0 0 0 0 0
> txtplunfl: 0
> txphyerr: 0
> pktengrxducast: 0
> pktengrxdmcast: 0
> rxfrmtoolong: 330
> rxfrmtooshrt: 16
> rxinvmachdr: 722
> rxbadfcs: 4306
> rxbadplcp: 7257
> rxcrsglitch: 61757
> rxstrt: 6667
> rxdfrmucastmbss: 41
> rxmfrmucastmbss: 25
> rxcfrmucast: 116
> rxrtsucast: 0
> rxctsucast: 59
> rxackucast: 19
> rxdfrmocast: 70
> rxmfrmocast: 84
> rxcfrmocast: 211
> rxrtsocast: 3
> rxctsocast: 20
> rxdfrmmcast: 9
> rxmfrmmcast: 1486
> rxcfrmmcast: 0
> rxbeaconmbss: 377
> rxdfrmucastobss: 0
> rxbeaconobss: 1086
> rxrsptmout: 94
> bcntxcancl: 0
> rxf0ovfl: 0
> rxf1ovfl: 0
> rxf2ovfl: 0
> txsfovfl: 0
> pmqovfl: 0
> rxcgprqfrm: 0
> rxcgprsqovfl: 0
> txcgprsfail: 0
> txcgprssuc: 0
> prs_timeout: 0
> rxnack: 0
> frmscons: 0
> txnack: 0
> txglitch_nack: 38
> txburst: 4
> bphy_rxcrsglitch: 2
> phywatchdog: 0
> bphy_badplcp: 0
>
>
> As far as I can see, the stats are never updated during stall,
> no numbers are changing, at least while the download is waiting
> for the next packet. Sometimes wpa_supplicant does something
> little, so some stats gets updated, eg, this is how it looks like
> after about 2..3 minutes:
>
> txallfrm: 420
> txrtsfrm: 201
> txctsfrm: 25
> txackfrm: 69
> txdnlfrm: 0
> txbcnfrm: 0
> txfunfl[8]: 0 0 0 0 0 0 0 0
> txtplunfl: 0
> txphyerr: 0
> pktengrxducast: 0
> pktengrxdmcast: 0
> rxfrmtoolong: 1908
> rxfrmtooshrt: 73
> rxinvmachdr: 4115
> rxbadfcs: 15064
> rxbadplcp: 42368
> rxcrsglitch: 36620
> rxstrt: 26393
> rxdfrmucastmbss: 48
> rxmfrmucastmbss: 27
> rxcfrmucast: 158
> rxrtsucast: 0
> rxctsucast: 92
> rxackucast: 25
> rxdfrmocast: 113
> rxmfrmocast: 390
> rxcfrmocast: 962
> rxrtsocast: 38
> rxctsocast: 59
> rxdfrmmcast: 48
> rxmfrmmcast: 7681
> rxcfrmmcast: 0
> rxbeaconmbss: 1505
> rxdfrmucastobss: 0
> rxbeaconobss: 6059
> rxrsptmout: 171
> bcntxcancl: 0
> rxf0ovfl: 0
> rxf1ovfl: 0
> rxf2ovfl: 0
> txsfovfl: 0
> pmqovfl: 0
> rxcgprqfrm: 0
> rxcgprsqovfl: 0
> txcgprsfail: 0
> txcgprssuc: 0
> prs_timeout: 0
> rxnack: 0
> frmscons: 0
> txnack: 0
> txglitch_nack: 41
> txburst: 4
> bphy_rxcrsglitch: 5
> phywatchdog: 0
> bphy_badplcp: 0
>
>
> This is with 3.18-tobe kernel (current Linus git).
>
> Dunno if this is helpful or not...
Well, it shows tx looks ok, but with download there is not much of that
going on. At least no large packets. However, I did find some missing
pieces related to bt-coex. Given that you device is a wifi-bt combo card
that is likely an issue for you. One of the missing pieces looks in
sprom for parameters and that is provided by bcma. However, it does not
seem to extract bt-coex related stuff. So I have attached a patch based
on 3.18-rc5 for bcma that dumps the sprom contents. Could you sent that
content to me.
Regards,
Arend
> Thanks,
>
> /mjt
>
[-- Attachment #2: 0001-bcma-dump-raw-sprom-content-for-debugging.patch --]
[-- Type: text/x-patch, Size: 981 bytes --]
>From 29cfa8ec164e2d742f98ddb2c5368b70540f5fab Mon Sep 17 00:00:00 2001
From: Arend van Spriel <arend@broadcom.com>
Date: Sun, 23 Nov 2014 10:26:17 +0100
Subject: [PATCH] bcma: dump raw sprom content for debugging
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
drivers/bcma/sprom.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/bcma/sprom.c b/drivers/bcma/sprom.c
index efb037f..0c246a4 100644
--- a/drivers/bcma/sprom.c
+++ b/drivers/bcma/sprom.c
@@ -129,10 +129,16 @@ static u8 bcma_sprom_crc(const u16 *sprom, size_t words)
int word;
u8 crc = 0xFF;
+ pr_debug(KBUILD_MODNAME "sprom:");
for (word = 0; word < words - 1; word++) {
+ if ((word % 10) == 0)
+ pr_debug("\n\t");
+ pr_debug("%04X ", sprom[word]);
crc = bcma_crc8(crc, sprom[word] & 0x00FF);
crc = bcma_crc8(crc, (sprom[word] & 0xFF00) >> 8);
}
+ if ((word % 10) == 0)
+ pr_debug("\n");
crc = bcma_crc8(crc, sprom[words - 1] & 0x00FF);
crc ^= 0xFF;
--
1.9.1
^ permalink raw reply related
* [PATCH] net: fec: init maximum receive buffer size for ring1 and ring2
From: Fugang Duan @ 2014-11-23 9:23 UTC (permalink / raw)
To: davem; +Cc: netdev, bhutchings, stephen, festevam, b38611
i.MX6SX fec support three rx ring1, the current driver lost to init
ring1 and ring2 maximum receive buffer size, that cause receving
frame date length error. The driver reports "rcv is not +last" error
log in user case.
Signed-off-by: Fugang Duan <B38611@freescale.com>
---
drivers/net/ethernet/freescale/fec.h | 11 +++++++++--
drivers/net/ethernet/freescale/fec_main.c | 4 +---
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 7aa9388..469691a 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -53,11 +53,13 @@
#define FEC_R_FSTART 0x150 /* FIFO receive start reg */
#define FEC_R_DES_START_1 0x160 /* Receive descriptor ring 1 */
#define FEC_X_DES_START_1 0x164 /* Transmit descriptor ring 1 */
+#define FEC_R_BUFF_SIZE_1 0x168 /* Maximum receive buff ring1 size */
#define FEC_R_DES_START_2 0x16c /* Receive descriptor ring 2 */
#define FEC_X_DES_START_2 0x170 /* Transmit descriptor ring 2 */
+#define FEC_R_BUFF_SIZE_2 0x174 /* Maximum receive buff ring2 size */
#define FEC_R_DES_START_0 0x180 /* Receive descriptor ring */
#define FEC_X_DES_START_0 0x184 /* Transmit descriptor ring */
-#define FEC_R_BUFF_SIZE 0x188 /* Maximum receive buff size */
+#define FEC_R_BUFF_SIZE_0 0x188 /* Maximum receive buff size */
#define FEC_R_FIFO_RSFL 0x190 /* Receive FIFO section full threshold */
#define FEC_R_FIFO_RSEM 0x194 /* Receive FIFO section empty threshold */
#define FEC_R_FIFO_RAEM 0x198 /* Receive FIFO almost empty threshold */
@@ -165,7 +167,9 @@
#define FEC_X_DES_START_0 0x3d4 /* Transmit descriptor ring */
#define FEC_X_DES_START_1 FEC_X_DES_START_0
#define FEC_X_DES_START_2 FEC_X_DES_START_0
-#define FEC_R_BUFF_SIZE 0x3d8 /* Maximum receive buff size */
+#define FEC_R_BUFF_SIZE_0 0x3d8 /* Maximum receive buff size */
+#define FEC_R_BUFF_SIZE_1 FEC_R_BUFF_SIZE_0
+#define FEC_R_BUFF_SIZE_2 FEC_R_BUFF_SIZE_0
#define FEC_FIFO_RAM 0x400 /* FIFO RAM buffer */
/* Not existed in real chip
* Just for pass build.
@@ -285,6 +289,9 @@ struct bufdesc_ex {
#define FEC_X_DES_START(X) (((X) == 1) ? FEC_X_DES_START_1 : \
(((X) == 2) ? \
FEC_X_DES_START_2 : FEC_X_DES_START_0))
+#define FEC_R_BUFF_SIZE(X) (((X) == 1) ? FEC_R_BUFF_SIZE_1 : \
+ (((X) == 2) ? \
+ FEC_R_BUFF_SIZE_2 : FEC_R_BUFF_SIZE_0))
#define FEC_R_DES_ACTIVE(X) (((X) == 1) ? FEC_R_DES_ACTIVE_1 : \
(((X) == 2) ? \
FEC_R_DES_ACTIVE_2 : FEC_R_DES_ACTIVE_0))
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1b6d26b..d2955ce 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -867,6 +867,7 @@ static void fec_enet_enable_ring(struct net_device *ndev)
for (i = 0; i < fep->num_rx_queues; i++) {
rxq = fep->rx_queue[i];
writel(rxq->bd_dma, fep->hwp + FEC_R_DES_START(i));
+ writel(PKT_MAXBLR_SIZE, fep->hwp + FEC_R_BUFF_SIZE(i));
/* enable DMA1/2 */
if (i)
@@ -941,9 +942,6 @@ fec_restart(struct net_device *ndev)
/* Clear any outstanding interrupt. */
writel(0xffc00000, fep->hwp + FEC_IEVENT);
- /* Set maximum receive buffer size. */
- writel(PKT_MAXBLR_SIZE, fep->hwp + FEC_R_BUFF_SIZE);
-
fec_enet_bd_init(ndev);
fec_enet_enable_ring(ndev);
--
1.7.8
^ permalink raw reply related
* Re: [PATCH net-next V1 1/2] ethtool: Support for configurable RSS hash function
From: Eyal perry @ 2014-11-23 10:13 UTC (permalink / raw)
To: David Miller, amirv
Cc: netdev, ben, ogerlitz, yevgenyp, eyalpe, thomas.lendacky,
ariel.elior, prashant, mchan, hariprasad, sathya.perla,
subbu.seetharaman, ajit.khaparde, jeffrey.t.kirsher,
jesse.brandeburg, bruce.w.allan, carolyn.wyborny,
donald.c.skidmore, gregory.v.rose, matthew.vick, john.ronciak,
mitch.a.williams, linux-net-drivers, sshah, sbhatewara,
pv-drivers
In-Reply-To: <20141122.165407.641057904952001007.davem@davemloft.net>
On 11/22/2014 11:54 PM, David Miller wrote:
> From: Amir Vadai <amirv@mellanox.com>
> Date: Thu, 20 Nov 2014 16:26:49 +0200
>
>> + /* We require at least one supported parameter to be changed and no
>> + * change in any of the unsupported parameters
>> + */
>> + if ((!indir && !key) || hfunc != ETH_RSS_HASH_NO_CHANGE)
>> + return -EOPNOTSUPP;
>> +
>
> I know it will make more work for you, but all of these driver
> implementations of this hook should:
>
> 1) Accept hfunc of whatever hash function the chip is using,
> not just ETH_RSS_HASH_NO_CHANGE.
>
> 2) Provide an accurate hfunc value in the ->get() call.
Ok, I'll do it for V2.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 net 1/2] drivers/net: Disable UFO through virtio
From: Michael S. Tsirkin @ 2014-11-23 10:33 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Hannes Frederic Sowa, virtualization
In-Reply-To: <1416595612.7215.21.camel@decadent.org.uk>
On Fri, Nov 21, 2014 at 06:46:52PM +0000, Ben Hutchings wrote:
> On Wed, 2014-11-19 at 11:14 +0200, Michael S. Tsirkin wrote:
> > On Thu, Oct 30, 2014 at 06:27:12PM +0000, Ben Hutchings wrote:
> > > IPv6 does not allow fragmentation by routers, so there is no
> > > fragmentation ID in the fixed header. UFO for IPv6 requires the ID to
> > > be passed separately, but there is no provision for this in the virtio
> > > net protocol.
> > >
> > > Until recently our software implementation of UFO/IPv6 generated a new
> > > ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet
> > > passed through a tap, which is even worse.
> > >
> > > Unfortunately there is no distinction between UFO/IPv4 and v6
> > > features, so disable UFO on taps and virtio_net completely until we
> > > have a proper solution.
> > >
> > > We cannot depend on VM managers respecting the tap feature flags, so
> > > keep accepting UFO packets but log a warning the first time we do
> > > this.
> > >
> > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > > Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
> >
> >
> > There's something I don't understand here. I see:
> >
> > NETIF_F_UFO_BIT, /* ... UDPv4 fragmentation */
> >
> > this comment is wrong then?
>
> Yes.
>
> > The patches drastically regress performance for UDPv4 for VMs only, but
> > isn't it likely many other devices based their code on this comment?
>
> There's only one hardware driver that implements UFO (s2io), and it does
> handle IPv6.
>
> > How about we disable UFO for IPv6 globally, and put the
> > flag back in?
> > We can then gradually add NETIF_F_UFO6_BIT for devices that
> > actually support UFO for IPv6.
>
> Since the corresponding virtio feature bit is understood to include
> UFO/IPv6, and existing VMs rely on that, I don't see what this solves.
>
> Ben.
I'm confused. Patching virtio has 0 effect on existing VMs - they
are running old drivers anyway.
Here's the proposal for guest side:
- Add NETIF_F_UFO6_BIT, set in s2io.
- Teach IPv6 to check NETIF_F_UFO6_BIT and not NETIF_F_UFO_BIT.
What is accomplishes is good speed for virtio with UDP over IPv4,
and correct, slower transmission for IPv6.
Of course this does not help old guests but your patch
to which I'm replying doesn't affect old guests either.
Or did I miss something?
> --
> Ben Hutchings
> Beware of bugs in the above code;
> I have only proved it correct, not tried it. - Donald Knuth
^ permalink raw reply
* Re: [PATCH net-net 0/4] Increase the limit of tuntap queues
From: Michael S. Tsirkin @ 2014-11-23 10:46 UTC (permalink / raw)
To: David Miller
Cc: pagupta, linux-kernel, netdev, jasowang, dgibson, vfalico,
edumazet, vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings,
xii, stephen, jiri, sergei.shtylyov
In-Reply-To: <20141119204427.GB30994@redhat.com>
On Wed, Nov 19, 2014 at 10:44:27PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 19, 2014 at 03:16:28PM -0500, David Miller wrote:
> > From: Pankaj Gupta <pagupta@redhat.com>
> > Date: Tue, 18 Nov 2014 21:52:54 +0530
> >
> > > - Accept maximum number of queues as sysctl param so that any user space
> > > application like libvirt can use this value to limit number of queues. Also
> > > Administrators can specify maximum number of queues by updating this sysctl
> > > entry.
> >
> > This is the only part I don't like.
> >
> > Just let whoever has privileges to configure the tun device shoot
> > themselves in the foot if they want to by configuring "too many"
> > queues.
> >
> > If the virtual entity runs itself out of resources by doing something
> > stupid, it's purely their problem.
>
> Well it will run host out of kernel, no?
To clarify:
At the moment attaching/detaching queues is an unpriveledged operation.
Shouldn't we worry that an application can cause large
allocations, and provide a way to limit these?
David, could you comment on this please?
> --
> MST
^ permalink raw reply
* RE: Resend - ANNOUNCE: Netdev 0.1 conference
From: Ariel Elior @ 2014-11-23 11:51 UTC (permalink / raw)
To: Jamal Hadi Salim, netdev
Cc: info@netdev01.info, David Miller, jaws@mojatatu.com,
rgb@tricolour.net
In-Reply-To: <546D57C4.8020800@mojatatu.com>
would you like to go?
________________________________________
From: netdev-owner@vger.kernel.org [netdev-owner@vger.kernel.org] on behalf of Jamal Hadi Salim [jhs@mojatatu.com]
Sent: Thursday, November 20, 2014 4:53 AM
To: netdev
Cc: info@netdev01.info; David Miller; jaws@mojatatu.com; rgb@tricolour.net
Subject: Resend - ANNOUNCE: Netdev 0.1 conference
Please forward to all places you think are relevant.
[original email i sent had the wrong contact info at the
bottom should be: info@netdev01.info]
Netdev 0.1 (year 0, conference 1) is a community-driven conference
geared towards Linux netheads. Linux kernel networking and user
space utilization of the interfaces to the Linux kernel networking
subsystem are the focus.
If you are using Linux as a boot system for proprietary networking,
then this conference _may not be for you_.
The netdev conference this year is structured to be 50/50
by-invitation and talk submission. We are making sure that we
reach out to speakers who have interesting relevant topics because
we recognize most of these folks would typically not be submitting
papers to a conference. The invitation will be made by the technical
committee to the individual speakers both for paper and tutorial
sessions.
The call for papers is for the 50% submission portion of the
conference for both paper submission as well as tutorials.
We *highly discourage* submission of recycled talks.
Current topics include
- wireless
- performance analysis and improvement
- networking hardware and offload
- netfilter
- traffic control
- different networking layers (L2/3, etc)
- internet of things
- security
- additional topics can be suggested
We encourage submission of papers and tutorials. Unlike other
conferences, we are going to try and accommodate as many submissions
as possible - but please stay within the relevant topic focus and
tie to Linux networking to make it easier for the technical committee
to provide quick feedback. In order to give a talk you must be
registered. If your proposal is accepted you will not be charged
a conference fee or your conference fee will be refunded to you
when your talk gets accepted.
We will be posting more updates on how to submit in the near future.
We expect about 3-4 parallel tracks both during tutorials and main
talks. Tutorials will be on the first day and talks on subsequent days.
Why you should register
-----------------------
If you yearn for the old community tech driven conferences where
you mingle with fellow geeks (only these would be Linux networking
geeks) then this would be it. There will be no marketing flashy
openings. There will just be a pure feed of Linux networking.
netdev 0.1 will be held back to back with netconf 2015, the
by-invite Linux kernel networking workshop
(http://vger.kernel.org/netconf2015.html).
So gurus of all sorts will be there mingling and giving talks.
While there will be heavy Linux kernel influence we expect a lot
of user space presence as well.
Location:
---------
Downtown Ottawa, Canada. Exact location to be announced.
www.netdev01.org
Important Dates:
----------------
November 26, 2014 Call for Papers opens
December 10, 2014 Registration opens
January 10, 2015 Call for sessions deadline
January 20, 2015 Conference schedule announced
February 14-17, 2015 Conference days
Please register as soon as registration opens up on December 10.
Registering helps us plan properly for numbers of attendees,
ensuring venue sizes and supplies are appropriate without
wasting resources.
contact:
--------
info@netdev01.info
^ permalink raw reply
* [PATCH] 8139too: The maximum MTU should allow for VLAN headers
From: Alban Bedel @ 2014-11-23 12:07 UTC (permalink / raw)
To: netdev
Cc: Ben Hutchings, Alban Bedel, David S. Miller, Eric W. Biederman,
Bjorn Helgaas, Benoit Taine, linux-kernel
As pointed out by Ben Hutchings drivers that allow using VLAN have to
provide enough headroom for the VLAN tags.
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/net/ethernet/realtek/8139too.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index e157541..63dc0f9 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -112,6 +112,7 @@
#include <linux/io.h>
#include <linux/uaccess.h>
#include <linux/gfp.h>
+#include <linux/if_vlan.h>
#include <asm/irq.h>
#define RTL8139_DRIVER_NAME DRV_NAME " Fast Ethernet driver " DRV_VERSION
@@ -182,13 +183,13 @@ static int debug = -1;
/* Number of Tx descriptor registers. */
#define NUM_TX_DESC 4
-/* max supported ethernet frame size -- must be at least (dev->mtu+14+4).*/
+/* max supported ethernet frame size -- must be at least (dev->mtu+18+4).*/
#define MAX_ETH_FRAME_SIZE 1792
/* max supported payload size */
-#define MAX_ETH_DATA_SIZE (MAX_ETH_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)
+#define MAX_ETH_DATA_SIZE (MAX_ETH_FRAME_SIZE - VLAN_ETH_HLEN - ETH_FCS_LEN)
-/* Size of the Tx bounce buffers -- must be at least (dev->mtu+14+4). */
+/* Size of the Tx bounce buffers -- must be at least (dev->mtu+18+4). */
#define TX_BUF_SIZE MAX_ETH_FRAME_SIZE
#define TX_BUF_TOT_LEN (TX_BUF_SIZE * NUM_TX_DESC)
--
2.0.0
^ permalink raw reply related
* Re:ciao
From: hi @ 2014-11-23 12:26 UTC (permalink / raw)
ciao
cominciamo a vendere iPhone 6 più, solo 450 euro. molto sorprendente
samsung s5, ipad .... w e b: assroooo. com
^ 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