* [PATCHv2 net-next 3/6] bridge: simplify the stp_state_store by calling store_bridge_parm
From: Xin Long @ 2016-04-05 3:32 UTC (permalink / raw)
To: network dev, bridge
Cc: davem, Stephen Hemminger, Hannes Frederic Sowa, nikolay
In-Reply-To: <cover.1459827115.git.lucien.xin@gmail.com>
There are some repetitive codes in stp_state_store, we can remove
them by calling store_bridge_parm.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/bridge/br_sysfs_br.c | 24 +++++++-----------------
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 137cd3b..9918763 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -128,27 +128,17 @@ static ssize_t stp_state_show(struct device *d,
}
+static int set_stp_state(struct net_bridge *br, unsigned long val)
+{
+ br_stp_set_enabled(br, val);
+ return 0;
+}
+
static ssize_t stp_state_store(struct device *d,
struct device_attribute *attr, const char *buf,
size_t len)
{
- struct net_bridge *br = to_bridge(d);
- char *endp;
- unsigned long val;
-
- if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN))
- return -EPERM;
-
- val = simple_strtoul(buf, &endp, 0);
- if (endp == buf)
- return -EINVAL;
-
- if (!rtnl_trylock())
- return restart_syscall();
- br_stp_set_enabled(br, val);
- rtnl_unlock();
-
- return len;
+ return store_bridge_parm(d, buf, len, set_stp_state);
}
static DEVICE_ATTR_RW(stp_state);
--
2.1.0
^ permalink raw reply related
* [PATCHv2 net-next 2/6] bridge: simplify the forward_delay_store by calling store_bridge_parm
From: Xin Long @ 2016-04-05 3:32 UTC (permalink / raw)
To: network dev, bridge
Cc: davem, Stephen Hemminger, Hannes Frederic Sowa, nikolay
In-Reply-To: <cover.1459827115.git.lucien.xin@gmail.com>
There are some repetitive codes in forward_delay_store, we can remove
them by calling store_bridge_parm.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/bridge/br_sysfs_br.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index c48f6b0..137cd3b 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -160,29 +160,22 @@ static ssize_t group_fwd_mask_show(struct device *d,
return sprintf(buf, "%#x\n", br->group_fwd_mask);
}
-
-static ssize_t group_fwd_mask_store(struct device *d,
- struct device_attribute *attr,
- const char *buf,
- size_t len)
+static int set_group_fwd_mask(struct net_bridge *br, unsigned long val)
{
- struct net_bridge *br = to_bridge(d);
- char *endp;
- unsigned long val;
-
- if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN))
- return -EPERM;
-
- val = simple_strtoul(buf, &endp, 0);
- if (endp == buf)
- return -EINVAL;
-
if (val & BR_GROUPFWD_RESTRICTED)
return -EINVAL;
br->group_fwd_mask = val;
- return len;
+ return 0;
+}
+
+static ssize_t group_fwd_mask_store(struct device *d,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t len)
+{
+ return store_bridge_parm(d, buf, len, set_group_fwd_mask);
}
static DEVICE_ATTR_RW(group_fwd_mask);
--
2.1.0
^ permalink raw reply related
* [PATCHv2 net-next 1/6] bridge: simplify the flush_store by calling store_bridge_parm
From: Xin Long @ 2016-04-05 3:32 UTC (permalink / raw)
To: network dev, bridge
Cc: davem, Stephen Hemminger, Hannes Frederic Sowa, nikolay
In-Reply-To: <cover.1459827115.git.lucien.xin@gmail.com>
There are some repetitive codes in flush_store, we can remove
them by calling store_bridge_parm, also, it would send rtnl notification
after we add it in store_bridge_parm in the following patches.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/bridge/br_sysfs_br.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 6b80914..c48f6b0 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -336,17 +336,17 @@ static ssize_t group_addr_store(struct device *d,
static DEVICE_ATTR_RW(group_addr);
+static int set_flush(struct net_bridge *br, unsigned long val)
+{
+ br_fdb_flush(br);
+ return 0;
+}
+
static ssize_t flush_store(struct device *d,
struct device_attribute *attr,
const char *buf, size_t len)
{
- struct net_bridge *br = to_bridge(d);
-
- if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN))
- return -EPERM;
-
- br_fdb_flush(br);
- return len;
+ return store_bridge_parm(d, buf, len, set_flush);
}
static DEVICE_ATTR_WO(flush);
--
2.1.0
^ permalink raw reply related
* [PATCHv2 net-next 0/6] bridge: support sending rntl info when we set attributes through sysfs/ioctl
From: Xin Long @ 2016-04-05 3:32 UTC (permalink / raw)
To: network dev, bridge
Cc: davem, Stephen Hemminger, Hannes Frederic Sowa, nikolay
This patchset is used to support sending rntl info to user in some places,
and ensure that whenever those attributes change internally or from sysfs,
that a netlink notification is sent out to listeners.
It also make some adjustment in bridge sysfs so that we can implement this
easily.
I've done some tests on this patchset, like:
[br_sysfs]
1. change all the attribute values of br or brif:
$ echo $value > /sys/class/net/br0/bridge/{*}
$ echo $value > /sys/class/net/br0/brif/eth1/{*}
2. meanwhile, on another terminal to observe the msg:
$ bridge monitor
[br_ioctl]
1. in bridge-utils package, do some changes in br_set, let brctl command
use ioctl to set attribute:
if ((ret = set_sysfs(path, value)) < 0) { -->
if (1) {
$ brctl set*
2. meanwhile, on another terminal to observe the msg:
$ bridge monitor
This test covers all the attributes that brctl and sysfs support to set.
Xin Long (6):
bridge: simplify the flush_store by calling store_bridge_parm
bridge: simplify the forward_delay_store by calling store_bridge_parm
bridge: simplify the stp_state_store by calling store_bridge_parm
bridge: a netlink notification should be sent when those attributes
are changed by br_sysfs_br
bridge: a netlink notification should be sent when those attributes
are changed by br_sysfs_if
bridge: a netlink notification should be sent when those attributes
are changed by ioctl
net/bridge/br_ioctl.c | 40 +++++++++++++----------
net/bridge/br_sysfs_br.c | 83 +++++++++++++++++++-----------------------------
net/bridge/br_sysfs_if.c | 5 +--
net/bridge/br_vlan.c | 30 +++--------------
4 files changed, 65 insertions(+), 93 deletions(-)
--
2.1.0
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Eric Dumazet @ 2016-04-05 2:44 UTC (permalink / raw)
To: Brenden Blanco
Cc: davem, netdev, tom, alexei.starovoitov, ogerlitz, daniel,
john.fastabend, brouer
In-Reply-To: <20160405022004.GA7677@gmail.com>
On Mon, 2016-04-04 at 19:20 -0700, Brenden Blanco wrote:
> On Sat, Apr 02, 2016 at 11:15:38PM -0700, Brenden Blanco wrote:
> > On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote:
> [...]
> > > 2) priv->stats.rx_dropped is shared by all the RX queues -> false
> > > sharing.
> > >
> > > This is probably the right time to add a rx_dropped field in struct
> > > mlx4_en_rx_ring since you guys want to drop 14 Mpps, and 50 Mpps on
> > > higher speed links.
> > >
> > This sounds reasonable! Will look into it for the next spin.
> I looked into this, and it seems to me that both the rx and tx dropped
> stats are buggy. With commit a3333b35da1634f49aca541f2574a084221e2616,
> specifically with the line
> stats->rx_dropped = be32_to_cpu(mlx4_en_stats->RDROP);
> that occurs during the periodic ethtool task, whatever ++ was happening
> in the rx/tx code is overwritten with the HW value. Since the SW stats
> are incremented mostly in edge (oom) cases, nobody probably noticed. To
> me it doesn't seem right to mix hard and soft counters, especially at
> the risk of making a bad situation worse, so I'm planning to omit the
> new bpf dropped++ stat and we can discuss ways to fix this other bug
> separately.
Yes, soft stats should not be overwritten.
Also adding 32bit and 64bit fields is wrong, as SNMP software are most
of the time not able to properly overflows.
^ permalink raw reply
* Re: [RFC PATCH 1/5] bpf: add PHYS_DEV prog type for early driver filter
From: Alexei Starovoitov @ 2016-04-05 2:25 UTC (permalink / raw)
To: Thomas Graf
Cc: Brenden Blanco, John Fastabend, Jesper Dangaard Brouer,
Tom Herbert, Daniel Borkmann, David S. Miller,
Linux Kernel Network Developers, ogerlitz
In-Reply-To: <20160404220439.GA9972@pox.localdomain>
On Tue, Apr 05, 2016 at 12:04:39AM +0200, Thomas Graf wrote:
> On 04/04/16 at 01:00pm, Alexei Starovoitov wrote:
> > Exactly. That the most important part of this rfc.
> > Right now redirect to different queue, batching, prefetch and tons of
> > other code are mising. We have to plan the whole project, so we can
> > incrementally add features without breaking abi.
> > So new IFLA, xdp_metadata struct and enum for bpf return codes are
> > the main things to agree on.
>
> +1
> This is the most important statement in this thread so far. A plan
> that gets us from this RFC series to a functional forwarding engine
> with redirect and load/write is essential. [...]
exactly. I think the next step 2 is to figure out the redirect return code
and 'rewiring' of the rx dma buffer into tx ring and auto-batching.
As this rfc showed even when using standard page alloc/free the peformance
is hitting 10Gbps hw limit and not being cpu bounded, so recycling of
the pages and avoiding map/unmap will come at step 3.
Batching is necessary even for basic redirect, since ringing doorbell
for every tx buffer is not an option.
> [...] I would really like to see a common set of helpers which
> applies to both cls_bpf and phys_dev. Given the existing skb based
> helpers cannot be overloaded, at least the phys_dev helpers should
> be made to work in cls_bpf context as well to allow for some
> portability. Otherwise we'll end up with half a dozen flavours of
> BPF which are all incompatible.
The helpers can be 'overloaded'. In my upcoming patches for
bpf+tracepoints the bpf_perf_event_output() helper is different
depending on program type (kprobe vs tracepoint), but logically
it looks exactly the same from program point of view and
BPF_FUNC_id is reused.
So for cls_bpf vs bpf_phys_dev we can have the same bpf_csum_diff()
helper which will have different internal implementation depending
on program type.
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Brenden Blanco @ 2016-04-05 2:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, netdev, tom, alexei.starovoitov, ogerlitz, daniel,
john.fastabend, brouer
In-Reply-To: <20160403061536.GD21980@gmail.com>
On Sat, Apr 02, 2016 at 11:15:38PM -0700, Brenden Blanco wrote:
> On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote:
[...]
> > 2) priv->stats.rx_dropped is shared by all the RX queues -> false
> > sharing.
> >
> > This is probably the right time to add a rx_dropped field in struct
> > mlx4_en_rx_ring since you guys want to drop 14 Mpps, and 50 Mpps on
> > higher speed links.
> >
> This sounds reasonable! Will look into it for the next spin.
I looked into this, and it seems to me that both the rx and tx dropped
stats are buggy. With commit a3333b35da1634f49aca541f2574a084221e2616,
specifically with the line
stats->rx_dropped = be32_to_cpu(mlx4_en_stats->RDROP);
that occurs during the periodic ethtool task, whatever ++ was happening
in the rx/tx code is overwritten with the HW value. Since the SW stats
are incremented mostly in edge (oom) cases, nobody probably noticed. To
me it doesn't seem right to mix hard and soft counters, especially at
the risk of making a bad situation worse, so I'm planning to omit the
new bpf dropped++ stat and we can discuss ways to fix this other bug
separately.
^ permalink raw reply
* Re: [PATCH v2 net-next 00/11] net: various udp/tcp changes
From: David Miller @ 2016-04-05 2:12 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, tom, willemb, ncardwell, maze
In-Reply-To: <1459525942-30399-1-git-send-email-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 1 Apr 2016 08:52:11 -0700
> First round of patches for linux-4.7
Nice series, applied.
I honestly think we can elide socket memory accounting for
(non-data-bearing) SYNACKs if that's showing up in the perf
profiles for SYN attacks.
^ permalink raw reply
* Re: [net-next v2 00/14][pull request] 10GbE Intel Wired LAN Driver Updates 2016-04-04
From: Jeff Kirsher @ 2016-04-05 2:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <20160404.220217.1293328475958277328.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Mon, 2016-04-04 at 22:02 -0400, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Mon, 04 Apr 2016 18:45:54 -0700
>
> >
> > On Mon, 2016-04-04 at 21:35 -0400, David Miller wrote:
> > >
> > > From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > Date: Mon, 4 Apr 2016 17:58:51 -0700
> > >
> > > >
> > > >
> > > > This series contains updates to ixgbe and ixgbevf.
> > > Pulled, thanks Jeff.
> > Dave, I f*'d up and forgot to push v2 to my kernel.org tree before
> > you
> > pulled. I have updated my 10GbE branch with the v2 series, if re-
> > pulling cause issues.
> >
> > If it will be problematic, I can add Alex's "fixup" patch to my
> > next
> > series.
> You are so lucky I didn't push out yet, I reverted and pulled from
> your tree again.
Thank you and so sorry I was absent minded.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next v2 00/14][pull request] 10GbE Intel Wired LAN Driver Updates 2016-04-04
From: David Miller @ 2016-04-05 2:02 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <1459820754.2965.4.camel@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 04 Apr 2016 18:45:54 -0700
> On Mon, 2016-04-04 at 21:35 -0400, David Miller wrote:
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Mon, 4 Apr 2016 17:58:51 -0700
>>
>> >
>> > This series contains updates to ixgbe and ixgbevf.
>> Pulled, thanks Jeff.
>
> Dave, I f*'d up and forgot to push v2 to my kernel.org tree before you
> pulled. I have updated my 10GbE branch with the v2 series, if re-
> pulling cause issues.
>
> If it will be problematic, I can add Alex's "fixup" patch to my next
> series.
You are so lucky I didn't push out yet, I reverted and pulled from
your tree again.
^ permalink raw reply
* Re: [net-next v2 00/14][pull request] 10GbE Intel Wired LAN Driver Updates 2016-04-04
From: Jeff Kirsher @ 2016-04-05 1:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <20160404.213504.1349389173676245770.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Mon, 2016-04-04 at 21:35 -0400, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Mon, 4 Apr 2016 17:58:51 -0700
>
> >
> > This series contains updates to ixgbe and ixgbevf.
> Pulled, thanks Jeff.
Dave, I f*'d up and forgot to push v2 to my kernel.org tree before you
pulled. I have updated my 10GbE branch with the v2 series, if re-
pulling cause issues.
If it will be problematic, I can add Alex's "fixup" patch to my next
series.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next v2 00/14][pull request] 10GbE Intel Wired LAN Driver Updates 2016-04-04
From: David Miller @ 2016-04-05 1:35 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <1459817945-144915-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 4 Apr 2016 17:58:51 -0700
> This series contains updates to ixgbe and ixgbevf.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: dsa: mv88e6131: HW bridging support for 6185
From: David Miller @ 2016-04-05 1:31 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, netdev, linux-kernel, kernel
In-Reply-To: <20160404021313.GB22003@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Mon, 4 Apr 2016 04:13:13 +0200
> On Thu, Mar 31, 2016 at 04:53:40PM -0400, Vivien Didelot wrote:
>> All packets passing through a switch of the 6185 family are currently all
>> directed to the CPU port. This means that port bridging is software driven.
>>
>> To enable hardware bridging for this switch family, we need to implement the
>> port mapping operations, the FDB operations, and optionally the VLAN operations
>> (for 802.1Q and VLAN filtering aware systems).
>>
>> However this family only has 256 FDBs indexed by 8-bit identifiers, opposed to
>> 4096 FDBs with 12-bit identifiers for other families such as 6352. It also
>> doesn't have dedicated FID registers for ATU and VTU operations.
>>
>> This patchset fixes these differences, and enable hardware bridging for 6185.
>
> Hi Vivien
>
> I added a test for in chip 6185 bridging, and it worked as expected.
>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [net-next 08/14] ixgbe: Add support for generic Tx checksums
From: Jeff Kirsher @ 2016-04-05 1:29 UTC (permalink / raw)
To: David Miller, sridhar.samudrala
Cc: aduyck, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20160404.212739.417828551756386273.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
On Mon, 2016-04-04 at 21:27 -0400, David Miller wrote:
> From: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
> Date: Mon, 04 Apr 2016 15:32:37 -0700
>
> >
> > On 4/4/2016 3:14 PM, Jeff Kirsher wrote:
> > >
> > > @@ -9190,41 +9148,37 @@ skip_sriov:
> > > #endif
> > > netdev->features = NETIF_F_SG |
> > > - NETIF_F_IP_CSUM |
> > > - NETIF_F_IPV6_CSUM |
> > > - NETIF_F_HW_VLAN_CTAG_TX |
> > > - NETIF_F_HW_VLAN_CTAG_RX |
> > > NETIF_F_TSO |
> > > NETIF_F_TSO6 |
> > > NETIF_F_RXHASH |
> > > - NETIF_F_RXCSUM;
> > > -
> > > - netdev->hw_features = netdev->features |
> > > NETIF_F_HW_L2FW_DOFFLOAD;
> > > + NETIF_F_RXCSUM |
> > > + NETIF_F_HW_CSUM |
> > > + NETIF_F_SCTP_CRC |
> > > + NETIF_F_HW_VLAN_CTAG_TX |
> > > + NETIF_F_HW_VLAN_CTAG_RX;
> > > - switch (adapter->hw.mac.type) {
> > > - case ixgbe_mac_82599EB:
> > > - case ixgbe_mac_X540:
> > > - case ixgbe_mac_X550:
> > > - case ixgbe_mac_X550EM_x:
> > > + if (hw->mac.type >= ixgbe_mac_82599EB)
> > > netdev->features |= NETIF_F_SCTP_CRC;
> > > - netdev->hw_features |= NETIF_F_SCTP_CRC |
> > > - NETIF_F_NTUPLE |
> > > - NETIF_F_HW_TC;
> > > - break;
> > > - default:
> > > - break;
> > > - }
> > > - netdev->hw_features |= NETIF_F_RXALL;
> > > + /* copy netdev features into list of user selectable
> > > features */
> > > + netdev->hw_features |= netdev->features;
> > > + netdev->hw_features |= NETIF_F_RXALL |
> > > + NETIF_F_HW_L2FW_DOFFLOAD;
> > > +
> > > + if (hw->mac.type >= ixgbe_mac_82599EB)
> > > + netdev->hw_features |= NETIF_F_NTUPLE;
> > looks like the cleanup missed moving NETIF_F_HW_TC flag here that
> > enables cls_u32 offloads via TC.
> Indeed, this is a regression.
I took care of it in v2.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: bcmgenet: fix dmadesc_set()
From: Florian Fainelli @ 2016-04-05 1:27 UTC (permalink / raw)
To: Petri Gynther; +Cc: netdev, David Miller, Jaedon Shin, opendmb, Eric Dumazet
In-Reply-To: <CAGXr9JHXbZ2r4ci7V95+-VKmuv3DOgE4i==kUAVJEDbG__h-+w@mail.gmail.com>
2016-04-04 18:11 GMT-07:00 Petri Gynther <pgynther@google.com>:
> Hi Florian,
>
> On Mon, Apr 4, 2016 at 5:58 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> 2016-04-04 17:10 GMT-07:00 Petri Gynther <pgynther@google.com>:
>> > dmadesc_set() is used for setting the Tx buffer DMA address, length,
>> > and status bits on a Tx ring descriptor when a frame is being Tx'ed.
>> >
>> > Always set the Tx buffer DMA address first, before updating the length
>> > and status bits, i.e. giving the Tx descriptor to the hardware.
>>
>> Does this fix any real bug you have observed? The hardware won't
>> transmit anything until you start writing the correct TDMA producer
>> index. Also, dmadesc_set_length_status and dmadesc_set_addr both use
>> I/O accessors which use a volatile, so they should not be re-ordered
>> relative to each other.
>>
>> I do agree that the change looks like how it should be done, I am just
>> questioning the qualification of this as a fix or not.
>>
>> Thanks!
>
> You are right. Nothing is transmitted until TDMA producer index is
> incremented, and that happens after dmadesc_set() has been called.
>
> So, this is really just a cleanup. Perhaps not worth it, after all.
OK, this is fine as a cleanup, and the typical logic is to write the
address first and the length/status second in case of descriptor-based
DMA-backed NICs, so why not.
>
> But I do have a question -- do we need wmb() in bcmgenet_xmit(), just
> before we kick the TDMA producer index, to ensure Tx descriptor writes
> have been completed?
Humm, that is a good question. We definitively need to make sure that
the writes to prod_index completes, since that variable is stored in
DRAM/normal memory, so subject to pre-fetching based on the memory
attributes (at least on ARM). It seems to me like there is a direct
dependency though, so by the time we use ring->prod_index, the CPU
should have ensured that all writes are complete.
>
> @@ -1606,6 +1606,7 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff
> *skb, struct net_device *dev)
>
> if (!skb->xmit_more || netif_xmit_stopped(txq)) {
> /* Packets are ready, update producer index */
> + wmb();
> bcmgenet_tdma_ring_writel(priv, ring->index,
> ring->prod_index, TDMA_PROD_INDEX);
>
>>
>>
>> >
>> > Signed-off-by: Petri Gynther <pgynther@google.com>
>> > ---
>> > drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> > index d77cd6d..f7b42b9 100644
>> > --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> > +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> > @@ -104,8 +104,8 @@ static inline void dmadesc_set_addr(struct bcmgenet_priv *priv,
>> > static inline void dmadesc_set(struct bcmgenet_priv *priv,
>> > void __iomem *d, dma_addr_t addr, u32 val)
>> > {
>> > - dmadesc_set_length_status(priv, d, val);
>> > dmadesc_set_addr(priv, d, addr);
>> > + dmadesc_set_length_status(priv, d, val);
>> > }
>> >
>> > static inline dma_addr_t dmadesc_get_addr(struct bcmgenet_priv *priv,
>> > --
>> > 2.8.0.rc3.226.g39d4020
>> >
>>
>>
>>
>> --
>> Florian
--
Florian
^ permalink raw reply
* Re: [net-next 08/14] ixgbe: Add support for generic Tx checksums
From: David Miller @ 2016-04-05 1:27 UTC (permalink / raw)
To: sridhar.samudrala
Cc: jeffrey.t.kirsher, aduyck, netdev, nhorman, sassmann, jogreene
In-Reply-To: <5702EB85.5080307@intel.com>
From: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Date: Mon, 04 Apr 2016 15:32:37 -0700
> On 4/4/2016 3:14 PM, Jeff Kirsher wrote:
>> @@ -9190,41 +9148,37 @@ skip_sriov:
>> #endif
>> netdev->features = NETIF_F_SG |
>> - NETIF_F_IP_CSUM |
>> - NETIF_F_IPV6_CSUM |
>> - NETIF_F_HW_VLAN_CTAG_TX |
>> - NETIF_F_HW_VLAN_CTAG_RX |
>> NETIF_F_TSO |
>> NETIF_F_TSO6 |
>> NETIF_F_RXHASH |
>> - NETIF_F_RXCSUM;
>> -
>> - netdev->hw_features = netdev->features | NETIF_F_HW_L2FW_DOFFLOAD;
>> + NETIF_F_RXCSUM |
>> + NETIF_F_HW_CSUM |
>> + NETIF_F_SCTP_CRC |
>> + NETIF_F_HW_VLAN_CTAG_TX |
>> + NETIF_F_HW_VLAN_CTAG_RX;
>> - switch (adapter->hw.mac.type) {
>> - case ixgbe_mac_82599EB:
>> - case ixgbe_mac_X540:
>> - case ixgbe_mac_X550:
>> - case ixgbe_mac_X550EM_x:
>> + if (hw->mac.type >= ixgbe_mac_82599EB)
>> netdev->features |= NETIF_F_SCTP_CRC;
>> - netdev->hw_features |= NETIF_F_SCTP_CRC |
>> - NETIF_F_NTUPLE |
>> - NETIF_F_HW_TC;
>> - break;
>> - default:
>> - break;
>> - }
>> - netdev->hw_features |= NETIF_F_RXALL;
>> + /* copy netdev features into list of user selectable features */
>> + netdev->hw_features |= netdev->features;
>> + netdev->hw_features |= NETIF_F_RXALL |
>> + NETIF_F_HW_L2FW_DOFFLOAD;
>> +
>> + if (hw->mac.type >= ixgbe_mac_82599EB)
>> + netdev->hw_features |= NETIF_F_NTUPLE;
>
> looks like the cleanup missed moving NETIF_F_HW_TC flag here that
> enables cls_u32 offloads via TC.
Indeed, this is a regression.
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Alexei Starovoitov @ 2016-04-05 1:17 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Johannes Berg, Brenden Blanco, davem, netdev, tom, ogerlitz,
john.fastabend, brouer
In-Reply-To: <5702D645.1090401@iogearbox.net>
On Mon, Apr 04, 2016 at 11:01:57PM +0200, Daniel Borkmann wrote:
> On 04/04/2016 08:46 PM, Alexei Starovoitov wrote:
> >On Mon, Apr 04, 2016 at 11:57:52AM +0200, Daniel Borkmann wrote:
> >>On 04/04/2016 09:35 AM, Johannes Berg wrote:
> >>>On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
> >>>>
> >>>>Having a common check makes sense. The tricky thing is that the type can
> >>>>only be checked after taking the reference, and I wanted to keep the
> >>>>scope of the prog brief in the case of errors. I would have to move the
> >>>>bpf_prog_get logic into dev_change_bpf_fd and pass a bpf_prog * into the
> >>>>ndo instead. Would that API look fine to you?
> >>>
> >>>I can't really comment, I wasn't planning on using the API right now :)
> >>>
> >>>However, what else is there that the driver could possibly do with the
> >>>FD, other than getting the bpf_prog?
> >>>
> >>>>A possible extension of this is just to keep the bpf_prog * in the
> >>>>netdev itself and expose a feature flag from the driver rather than
> >>>>an ndo. But that would mean another 8 bytes in the netdev.
> >>>
> >>>That also misses the signal to the driver when the program is
> >>>set/removed, so I don't think that works. I'd argue it's not really
> >>>desirable anyway though since I wouldn't expect a majority of drivers
> >>>to start supporting this.
> >>
> >>I think ndo is probably fine for this purpose, see also my other mail. I
> >>think currently, the only really driver specific code would be to store
> >>the prog pointer somewhere and to pass needed meta data to populate the
> >>fake skb.
> >
> >yes. I think ndo is better and having bpf_prog in the driver priv
> >part is likely better as well, since driver may decide to put it into
> >their ring struct for faster fetch or layout prog pointer next to other
> >priv fields for better cache.
> >Having prog in 'struct net_device' may look very sensible right now,
> >since there is not much code around it, but later it may be causing
> >some performance headachces. I think it's better to have complete
> >freedom in the drivers and later move code to generic part.
> >Same applies to your other comment about moving mlx4_bpf_set() and
> >mlx4_call_bpf() into generic. It's better for them to be driver
> >specific in the moment. Right now we have only mlx4 anyway.
>
> Sure, right now it's only mlx4, but we need to make sure that once this gets
> adapted/extended by others, that we won't end up with programs that can only
> be run by specific drivers e.g., due to meta data only available for this kind
> of driver but not others supporting XDP. So, some form of generic part will
> be needed in any case, also makes it easier for testing changes.
yes. if packet metadata becomes different for different drivers it will
be a major pain to write portable programs and we should strive to avoid that.
Right now it's only 'len' which obviously available everywhere and any new
field need to be argued for.
Same will apply to helper functions. In this rfc it's just sk_filter_func_proto,
which is a good set for filtering packets, but load/store bytes + csum helpers
need to be added along with packet redirect to be useful for eth2eth traffic.
Since there is no skb and there is no legacy of LD_ABS with negative offsets,
we can have direct load/store bytes, so csum operations may become instructions
as well and will be faster too. Yes. It would mean that tc+cls_bpf have to look
different in bpf assembler, but since they're written in C we can abstract
them at user space C level and can have the same program compiled as cls_bpf
using cls_bpf helpers and as bpf_phys_dev using direct load/store instructions.
Like bpf_skb_load_bytes() may become inlined memcpy with extra len check
for bpf_phys_dev prog type. All options are open.
The only thing we cannot compromise on is max performance.
If performance suffers due to generality/legacy_code/compatiblity_with_X_or_Y,
we should pick performance.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: bcmgenet: fix dmadesc_set()
From: Petri Gynther @ 2016-04-05 1:11 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, David Miller, Jaedon Shin, opendmb
In-Reply-To: <CAGVrzca5=a3tewe=DGpYZwmk38NTWOjpZFyYxJGJue=OgDGo=w@mail.gmail.com>
Hi Florian,
On Mon, Apr 4, 2016 at 5:58 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> 2016-04-04 17:10 GMT-07:00 Petri Gynther <pgynther@google.com>:
> > dmadesc_set() is used for setting the Tx buffer DMA address, length,
> > and status bits on a Tx ring descriptor when a frame is being Tx'ed.
> >
> > Always set the Tx buffer DMA address first, before updating the length
> > and status bits, i.e. giving the Tx descriptor to the hardware.
>
> Does this fix any real bug you have observed? The hardware won't
> transmit anything until you start writing the correct TDMA producer
> index. Also, dmadesc_set_length_status and dmadesc_set_addr both use
> I/O accessors which use a volatile, so they should not be re-ordered
> relative to each other.
>
> I do agree that the change looks like how it should be done, I am just
> questioning the qualification of this as a fix or not.
>
> Thanks!
You are right. Nothing is transmitted until TDMA producer index is
incremented, and that happens after dmadesc_set() has been called.
So, this is really just a cleanup. Perhaps not worth it, after all.
But I do have a question -- do we need wmb() in bcmgenet_xmit(), just
before we kick the TDMA producer index, to ensure Tx descriptor writes
have been completed?
@@ -1606,6 +1606,7 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff
*skb, struct net_device *dev)
if (!skb->xmit_more || netif_xmit_stopped(txq)) {
/* Packets are ready, update producer index */
+ wmb();
bcmgenet_tdma_ring_writel(priv, ring->index,
ring->prod_index, TDMA_PROD_INDEX);
>
>
> >
> > Signed-off-by: Petri Gynther <pgynther@google.com>
> > ---
> > drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> > index d77cd6d..f7b42b9 100644
> > --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> > +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> > @@ -104,8 +104,8 @@ static inline void dmadesc_set_addr(struct bcmgenet_priv *priv,
> > static inline void dmadesc_set(struct bcmgenet_priv *priv,
> > void __iomem *d, dma_addr_t addr, u32 val)
> > {
> > - dmadesc_set_length_status(priv, d, val);
> > dmadesc_set_addr(priv, d, addr);
> > + dmadesc_set_length_status(priv, d, val);
> > }
> >
> > static inline dma_addr_t dmadesc_get_addr(struct bcmgenet_priv *priv,
> > --
> > 2.8.0.rc3.226.g39d4020
> >
>
>
>
> --
> Florian
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: bcmgenet: cleanup for bcmgenet_xmit_frag()
From: Florian Fainelli @ 2016-04-05 1:00 UTC (permalink / raw)
To: Petri Gynther; +Cc: netdev, David Miller, Jaedon Shin
In-Reply-To: <1459815001-91703-2-git-send-email-pgynther@google.com>
2016-04-04 17:10 GMT-07:00 Petri Gynther <pgynther@google.com>:
> Add frag_size = skb_frag_size(frag) and use it when needed.
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: bcmgenet: cleanup for bcmgenet_xmit()
From: Florian Fainelli @ 2016-04-05 0:58 UTC (permalink / raw)
To: Petri Gynther, opendmb; +Cc: netdev, David Miller, Jaedon Shin
In-Reply-To: <1459815001-91703-1-git-send-email-pgynther@google.com>
2016-04-04 17:09 GMT-07:00 Petri Gynther <pgynther@google.com>:
> 1. Readability: Move nr_frags assignment a few lines down in order
> to bundle index -> ring -> txq calculations together.
> 2. Readability: Add parentheses around nr_frags + 1.
> 3. Minor fix: Stop the Tx queue and throw the error message only if
> the Tx queue hasn't already been stopped.
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
^ permalink raw reply
* [net-next v2 14/14] ixgbe: Add support for toggling VLAN filtering flag via ethtool
From: Jeff Kirsher @ 2016-04-05 0:59 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1459817945-144915-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <aduyck@mirantis.com>
This change makes it so that we can use the ethtool rx-vlan-filter flag to
toggle Rx VLAN filtering on and off. This is basically just an extension
of the existing VLAN promisc work in that it just adds support for the
additional ethtool flag.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 359869c..19bf386 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4447,6 +4447,7 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
struct ixgbe_adapter *adapter = netdev_priv(netdev);
struct ixgbe_hw *hw = &adapter->hw;
u32 fctrl, vmolr = IXGBE_VMOLR_BAM | IXGBE_VMOLR_AUPE;
+ netdev_features_t features = netdev->features;
int count;
/* Check for Promiscuous and All Multicast modes */
@@ -4464,14 +4465,13 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
hw->addr_ctrl.user_set_promisc = true;
fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
vmolr |= IXGBE_VMOLR_MPE;
- ixgbe_vlan_promisc_enable(adapter);
+ features &= ~NETIF_F_HW_VLAN_CTAG_FILTER;
} else {
if (netdev->flags & IFF_ALLMULTI) {
fctrl |= IXGBE_FCTRL_MPE;
vmolr |= IXGBE_VMOLR_MPE;
}
hw->addr_ctrl.user_set_promisc = false;
- ixgbe_vlan_promisc_disable(adapter);
}
/*
@@ -4504,7 +4504,7 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
}
/* This is useful for sniffing bad packets. */
- if (adapter->netdev->features & NETIF_F_RXALL) {
+ if (features & NETIF_F_RXALL) {
/* UPE and MPE will be handled by normal PROMISC logic
* in e1000e_set_rx_mode */
fctrl |= (IXGBE_FCTRL_SBP | /* Receive bad packets */
@@ -4517,10 +4517,15 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
IXGBE_WRITE_REG(hw, IXGBE_FCTRL, fctrl);
- if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX)
+ if (features & NETIF_F_HW_VLAN_CTAG_RX)
ixgbe_vlan_strip_enable(adapter);
else
ixgbe_vlan_strip_disable(adapter);
+
+ if (features & NETIF_F_HW_VLAN_CTAG_FILTER)
+ ixgbe_vlan_promisc_disable(adapter);
+ else
+ ixgbe_vlan_promisc_enable(adapter);
}
static void ixgbe_napi_enable_all(struct ixgbe_adapter *adapter)
@@ -8495,11 +8500,6 @@ static int ixgbe_set_features(struct net_device *netdev,
adapter->flags |= IXGBE_FLAG_FDIR_HASH_CAPABLE;
}
- if (features & NETIF_F_HW_VLAN_CTAG_RX)
- ixgbe_vlan_strip_enable(adapter);
- else
- ixgbe_vlan_strip_disable(adapter);
-
if (changed & NETIF_F_RXALL)
need_reset = true;
@@ -8516,6 +8516,9 @@ static int ixgbe_set_features(struct net_device *netdev,
if (need_reset)
ixgbe_do_reset(netdev);
+ else if (changed & (NETIF_F_HW_VLAN_CTAG_RX |
+ NETIF_F_HW_VLAN_CTAG_FILTER))
+ ixgbe_set_rx_mode(netdev);
return 0;
}
@@ -9190,7 +9193,8 @@ skip_sriov:
NETIF_F_RXCSUM |
NETIF_F_HW_CSUM |
NETIF_F_HW_VLAN_CTAG_TX |
- NETIF_F_HW_VLAN_CTAG_RX;
+ NETIF_F_HW_VLAN_CTAG_RX |
+ NETIF_F_HW_VLAN_CTAG_FILTER;
if (hw->mac.type >= ixgbe_mac_82599EB)
netdev->features |= NETIF_F_SCTP_CRC;
@@ -9204,9 +9208,6 @@ skip_sriov:
netdev->hw_features |= NETIF_F_NTUPLE |
NETIF_F_HW_TC;
- /* set this bit last since it cannot be part of hw_features */
- netdev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
-
netdev->vlan_features |= NETIF_F_SG |
NETIF_F_TSO |
NETIF_F_TSO6 |
--
2.5.5
^ permalink raw reply related
* [net-next v2 13/14] ixgbe: Extend cls_u32 offload to support UDP headers
From: Jeff Kirsher @ 2016-04-05 0:59 UTC (permalink / raw)
To: davem; +Cc: Amritha Nambiar, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1459817945-144915-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Amritha Nambiar <amritha.nambiar@intel.com>
Added support to match on UDP fields in the transport layer.
Extended core logic to support multiple headers.
Verified with the following filters :
handle 1: u32 divisor 1
u32 ht 800: order 1 link 1: \
offset at 0 mask 0f00 shift 6 plus 0 eat match ip protocol 6 ff
u32 ht 1: order 2 \
match tcp src 1024 ffff match tcp dst 23 ffff action drop
handle 2: u32 divisor 1
u32 ht 800: order 3 link 2: \
offset at 0 mask 0f00 shift 6 plus 0 eat match ip protocol 17 ff
u32 ht 2: order 4 \
match udp src 1025 ffff match udp dst 24 ffff action drop
Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19 ++++++++++---------
drivers/net/ethernet/intel/ixgbe/ixgbe_model.h | 8 ++++++++
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 77c1c85..359869c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -8257,19 +8257,20 @@ static int ixgbe_configure_clsu32(struct ixgbe_adapter *adapter,
return -EINVAL;
for (i = 0; nexthdr[i].jump; i++) {
- if (nexthdr->o != cls->knode.sel->offoff ||
- nexthdr->s != cls->knode.sel->offshift ||
- nexthdr->m != cls->knode.sel->offmask ||
+ if (nexthdr[i].o != cls->knode.sel->offoff ||
+ nexthdr[i].s != cls->knode.sel->offshift ||
+ nexthdr[i].m != cls->knode.sel->offmask ||
/* do not support multiple key jumps its just mad */
cls->knode.sel->nkeys > 1)
return -EINVAL;
- if (nexthdr->off != cls->knode.sel->keys[0].off ||
- nexthdr->val != cls->knode.sel->keys[0].val ||
- nexthdr->mask != cls->knode.sel->keys[0].mask)
- return -EINVAL;
-
- adapter->jump_tables[link_uhtid] = nexthdr->jump;
+ if (nexthdr[i].off == cls->knode.sel->keys[0].off &&
+ nexthdr[i].val == cls->knode.sel->keys[0].val &&
+ nexthdr[i].mask == cls->knode.sel->keys[0].mask) {
+ adapter->jump_tables[link_uhtid] =
+ nexthdr[i].jump;
+ break;
+ }
}
return 0;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h
index 74c53ad..60adde5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h
@@ -82,6 +82,12 @@ static struct ixgbe_mat_field ixgbe_tcp_fields[] = {
{ .val = NULL } /* terminal node */
};
+static struct ixgbe_mat_field ixgbe_udp_fields[] = {
+ {.off = 0, .val = ixgbe_mat_prgm_ports,
+ .type = IXGBE_ATR_FLOW_TYPE_UDPV4},
+ { .val = NULL } /* terminal node */
+};
+
struct ixgbe_nexthdr {
/* offset, shift, and mask of position to next header */
unsigned int o;
@@ -98,6 +104,8 @@ struct ixgbe_nexthdr {
static struct ixgbe_nexthdr ixgbe_ipv4_jumps[] = {
{ .o = 0, .s = 6, .m = 0xf,
.off = 8, .val = 0x600, .mask = 0xff00, .jump = ixgbe_tcp_fields},
+ { .o = 0, .s = 6, .m = 0xf,
+ .off = 8, .val = 0x1100, .mask = 0xff00, .jump = ixgbe_udp_fields},
{ .jump = NULL } /* terminal node */
};
#endif /* _IXGBE_MODEL_H_ */
--
2.5.5
^ permalink raw reply related
* [net-next v2 12/14] ixgbe: Place SWFW semaphore in known valid state at probe
From: Jeff Kirsher @ 2016-04-05 0:59 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1459817945-144915-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
It is possible on some HW that a system reset could occur when we are
holding the SWFW semaphore lock. So next time the driver was loaded we
would see it incorrectly as locked. This patch will recover from that state
by: Attempting to acquire the semaphore and then regardless of whether or
not it was acquire we immediately release it. This will force us into
a known good state.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++++
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 20 ++++++++++++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 ++
7 files changed, 30 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index f47eb12..6ecd598 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1196,6 +1196,7 @@ static const struct ixgbe_mac_operations mac_ops_82598 = {
.set_fw_drv_ver = NULL,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync,
.release_swfw_sync = &ixgbe_release_swfw_sync,
+ .init_swfw_sync = NULL,
.get_thermal_sensor_data = NULL,
.init_thermal_sensor_thresh = NULL,
.prot_autoc_read = &prot_autoc_read_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index c3ae5a7..4bb6b68 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -2228,6 +2228,7 @@ static const struct ixgbe_mac_operations mac_ops_82599 = {
.set_vlan_anti_spoofing = &ixgbe_set_vlan_anti_spoofing,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync,
.release_swfw_sync = &ixgbe_release_swfw_sync,
+ .init_swfw_sync = NULL,
.get_thermal_sensor_data = &ixgbe_get_thermal_sensor_data_generic,
.init_thermal_sensor_thresh = &ixgbe_init_thermal_sensor_thresh_generic,
.prot_autoc_read = &prot_autoc_read_82599,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 115656c..77c1c85 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9126,6 +9126,10 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (err)
goto err_sw_init;
+ /* Make sure the SWFW semaphore is in a valid state */
+ if (hw->mac.ops.init_swfw_sync)
+ hw->mac.ops.init_swfw_sync(hw);
+
/* Make it possible the adapter to be woken up via WOL */
switch (adapter->hw.mac.type) {
case ixgbe_mac_82599EB:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 787d2b2..bc012ab 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -3266,6 +3266,7 @@ struct ixgbe_mac_operations {
s32 (*enable_rx_dma)(struct ixgbe_hw *, u32);
s32 (*acquire_swfw_sync)(struct ixgbe_hw *, u32);
void (*release_swfw_sync)(struct ixgbe_hw *, u32);
+ void (*init_swfw_sync)(struct ixgbe_hw *);
s32 (*prot_autoc_read)(struct ixgbe_hw *, bool *, u32 *);
s32 (*prot_autoc_write)(struct ixgbe_hw *, u32, bool);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
index c00b67b..40824d8 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
@@ -747,6 +747,25 @@ static void ixgbe_release_swfw_sync_semaphore(struct ixgbe_hw *hw)
}
/**
+ * ixgbe_init_swfw_sync_X540 - Release hardware semaphore
+ * @hw: pointer to hardware structure
+ *
+ * This function reset hardware semaphore bits for a semaphore that may
+ * have be left locked due to a catastrophic failure.
+ **/
+void ixgbe_init_swfw_sync_X540(struct ixgbe_hw *hw)
+{
+ /* First try to grab the semaphore but we don't need to bother
+ * looking to see whether we got the lock or not since we do
+ * the same thing regardless of whether we got the lock or not.
+ * We got the lock - we release it.
+ * We timeout trying to get the lock - we force its release.
+ */
+ ixgbe_get_swfw_sync_semaphore(hw);
+ ixgbe_release_swfw_sync_semaphore(hw);
+}
+
+/**
* ixgbe_blink_led_start_X540 - Blink LED based on index.
* @hw: pointer to hardware structure
* @index: led number to blink
@@ -854,6 +873,7 @@ static const struct ixgbe_mac_operations mac_ops_X540 = {
.set_vlan_anti_spoofing = &ixgbe_set_vlan_anti_spoofing,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync_X540,
.release_swfw_sync = &ixgbe_release_swfw_sync_X540,
+ .init_swfw_sync = &ixgbe_init_swfw_sync_X540,
.disable_rx_buff = &ixgbe_disable_rx_buff_generic,
.enable_rx_buff = &ixgbe_enable_rx_buff_generic,
.get_thermal_sensor_data = NULL,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.h
index a1468b1..e21cd48 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.h
@@ -36,4 +36,5 @@ s32 ixgbe_blink_led_start_X540(struct ixgbe_hw *hw, u32 index);
s32 ixgbe_blink_led_stop_X540(struct ixgbe_hw *hw, u32 index);
s32 ixgbe_acquire_swfw_sync_X540(struct ixgbe_hw *hw, u32 mask);
void ixgbe_release_swfw_sync_X540(struct ixgbe_hw *hw, u32 mask);
+void ixgbe_init_swfw_sync_X540(struct ixgbe_hw *hw);
s32 ixgbe_init_eeprom_params_X540(struct ixgbe_hw *hw);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index 972c9aa..9d3f765 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -2432,6 +2432,7 @@ static const struct ixgbe_mac_operations mac_ops_X550 = {
.setup_sfp = NULL,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync_X540,
.release_swfw_sync = &ixgbe_release_swfw_sync_X540,
+ .init_swfw_sync = &ixgbe_init_swfw_sync_X540,
.prot_autoc_read = prot_autoc_read_generic,
.prot_autoc_write = prot_autoc_write_generic,
.setup_fc = ixgbe_setup_fc_generic,
@@ -2449,6 +2450,7 @@ static const struct ixgbe_mac_operations mac_ops_X550EM_x = {
.setup_sfp = ixgbe_setup_sfp_modules_X550em,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync_X550em,
.release_swfw_sync = &ixgbe_release_swfw_sync_X550em,
+ .init_swfw_sync = &ixgbe_init_swfw_sync_X540,
.setup_fc = NULL, /* defined later */
};
--
2.5.5
^ permalink raw reply related
* [net-next v2 10/14] ixgbe: Fix flow control for Xeon D KR backplane
From: Jeff Kirsher @ 2016-04-05 0:59 UTC (permalink / raw)
To: davem; +Cc: Mark Rustad, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1459817945-144915-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Mark Rustad <mark.d.rustad@intel.com>
Xeon D KR backplane is different from other backplanes,
in that we can't use auto-negotiation to determine the
mode. Instead, use whatever the user configured.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 8 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 5 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 86 ++++++++++++++++++++++++-
7 files changed, 98 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index 9790d02..f47eb12 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1192,6 +1192,7 @@ static const struct ixgbe_mac_operations mac_ops_82598 = {
.clear_vfta = &ixgbe_clear_vfta_82598,
.set_vfta = &ixgbe_set_vfta_82598,
.fc_enable = &ixgbe_fc_enable_82598,
+ .setup_fc = ixgbe_setup_fc_generic,
.set_fw_drv_ver = NULL,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync,
.release_swfw_sync = &ixgbe_release_swfw_sync,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index b276fe0..c3ae5a7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -2220,6 +2220,7 @@ static const struct ixgbe_mac_operations mac_ops_82599 = {
.clear_vfta = &ixgbe_clear_vfta_generic,
.set_vfta = &ixgbe_set_vfta_generic,
.fc_enable = &ixgbe_fc_enable_generic,
+ .setup_fc = ixgbe_setup_fc_generic,
.set_fw_drv_ver = &ixgbe_set_fw_drv_ver_generic,
.init_uta_tables = &ixgbe_init_uta_tables_generic,
.setup_sfp = &ixgbe_setup_sfp_modules_82599,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 6404505..8c7e78b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -1,7 +1,7 @@
/*******************************************************************************
Intel 10 Gigabit PCI Express Linux driver
- Copyright(c) 1999 - 2015 Intel Corporation.
+ Copyright(c) 1999 - 2016 Intel Corporation.
This program is free software; you can redistribute it and/or modify it
under the terms and conditions of the GNU General Public License,
@@ -111,12 +111,12 @@ bool ixgbe_device_supports_autoneg_fc(struct ixgbe_hw *hw)
}
/**
- * ixgbe_setup_fc - Set up flow control
+ * ixgbe_setup_fc_generic - Set up flow control
* @hw: pointer to hardware structure
*
* Called at init time to set up flow control.
**/
-static s32 ixgbe_setup_fc(struct ixgbe_hw *hw)
+s32 ixgbe_setup_fc_generic(struct ixgbe_hw *hw)
{
s32 ret_val = 0;
u32 reg = 0, reg_bp = 0;
@@ -296,7 +296,7 @@ s32 ixgbe_start_hw_generic(struct ixgbe_hw *hw)
IXGBE_WRITE_FLUSH(hw);
/* Setup flow control */
- ret_val = ixgbe_setup_fc(hw);
+ ret_val = hw->mac.ops.setup_fc(hw);
if (ret_val)
return ret_val;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index 2b95631..2e29015 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -1,7 +1,7 @@
/*******************************************************************************
Intel 10 Gigabit PCI Express Linux driver
- Copyright(c) 1999 - 2014 Intel Corporation.
+ Copyright(c) 1999 - 2016 Intel Corporation.
This program is free software; you can redistribute it and/or modify it
under the terms and conditions of the GNU General Public License,
@@ -81,6 +81,7 @@ s32 ixgbe_disable_rx_buff_generic(struct ixgbe_hw *hw);
s32 ixgbe_enable_rx_buff_generic(struct ixgbe_hw *hw);
s32 ixgbe_enable_rx_dma_generic(struct ixgbe_hw *hw, u32 regval);
s32 ixgbe_fc_enable_generic(struct ixgbe_hw *hw);
+s32 ixgbe_setup_fc_generic(struct ixgbe_hw *);
bool ixgbe_device_supports_autoneg_fc(struct ixgbe_hw *hw);
void ixgbe_fc_autoneg(struct ixgbe_hw *hw);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 29e0b0e..787d2b2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -3308,6 +3308,7 @@ struct ixgbe_mac_operations {
/* Flow Control */
s32 (*fc_enable)(struct ixgbe_hw *);
+ s32 (*setup_fc)(struct ixgbe_hw *);
/* Manageability interface */
s32 (*set_fw_drv_ver)(struct ixgbe_hw *, u8, u8, u8, u8);
@@ -3525,6 +3526,7 @@ struct ixgbe_info {
#define IXGBE_KRM_PORT_CAR_GEN_CTRL(P) ((P) ? 0x8010 : 0x4010)
#define IXGBE_KRM_LINK_CTRL_1(P) ((P) ? 0x820C : 0x420C)
+#define IXGBE_KRM_AN_CNTL_1(P) ((P) ? 0x822C : 0x422C)
#define IXGBE_KRM_DSP_TXFFE_STATE_4(P) ((P) ? 0x8634 : 0x4634)
#define IXGBE_KRM_DSP_TXFFE_STATE_5(P) ((P) ? 0x8638 : 0x4638)
#define IXGBE_KRM_RX_TRN_LINKUP_CTRL(P) ((P) ? 0x8B00 : 0x4B00)
@@ -3547,6 +3549,9 @@ struct ixgbe_info {
#define IXGBE_KRM_LINK_CTRL_1_TETH_AN_ENABLE (1 << 29)
#define IXGBE_KRM_LINK_CTRL_1_TETH_AN_RESTART (1 << 31)
+#define IXGBE_KRM_AN_CNTL_1_SYM_PAUSE (1 << 28)
+#define IXGBE_KRM_AN_CNTL_1_ASM_PAUSE (1 << 29)
+
#define IXGBE_KRM_DSP_TXFFE_STATE_C0_EN (1 << 6)
#define IXGBE_KRM_DSP_TXFFE_STATE_CP1_CN1_EN (1 << 15)
#define IXGBE_KRM_DSP_TXFFE_STATE_CO_ADAPT_EN (1 << 16)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
index 0d69564..c00b67b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
@@ -846,6 +846,7 @@ static const struct ixgbe_mac_operations mac_ops_X540 = {
.clear_vfta = &ixgbe_clear_vfta_generic,
.set_vfta = &ixgbe_set_vfta_generic,
.fc_enable = &ixgbe_fc_enable_generic,
+ .setup_fc = ixgbe_setup_fc_generic,
.set_fw_drv_ver = &ixgbe_set_fw_drv_ver_generic,
.init_uta_tables = &ixgbe_init_uta_tables_generic,
.setup_sfp = NULL,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index 26e0b8d..972c9aa 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -27,6 +27,7 @@
#include "ixgbe_phy.h"
static s32 ixgbe_setup_kr_speed_x550em(struct ixgbe_hw *, ixgbe_link_speed);
+static s32 ixgbe_setup_fc_x550em(struct ixgbe_hw *);
static s32 ixgbe_get_invariants_X550_x(struct ixgbe_hw *hw)
{
@@ -1342,15 +1343,18 @@ static void ixgbe_init_mac_link_ops_X550em(struct ixgbe_hw *hw)
mac->ops.enable_tx_laser = NULL;
mac->ops.flap_tx_laser = NULL;
mac->ops.setup_link = ixgbe_setup_mac_link_multispeed_fiber;
+ mac->ops.setup_fc = ixgbe_setup_fc_x550em;
mac->ops.setup_mac_link = ixgbe_setup_mac_link_sfp_x550em;
mac->ops.set_rate_select_speed =
ixgbe_set_soft_rate_select_speed;
break;
case ixgbe_media_type_copper:
mac->ops.setup_link = ixgbe_setup_mac_link_t_X550em;
+ mac->ops.setup_fc = ixgbe_setup_fc_generic;
mac->ops.check_link = ixgbe_check_link_t_X550em;
break;
default:
+ mac->ops.setup_fc = ixgbe_setup_fc_x550em;
break;
}
}
@@ -1842,6 +1846,82 @@ static s32 ixgbe_get_lcd_t_x550em(struct ixgbe_hw *hw,
return status;
}
+/**
+ * ixgbe_setup_fc_x550em - Set up flow control
+ * @hw: pointer to hardware structure
+ */
+static s32 ixgbe_setup_fc_x550em(struct ixgbe_hw *hw)
+{
+ bool pause, asm_dir;
+ u32 reg_val;
+ s32 rc;
+
+ /* Validate the requested mode */
+ if (hw->fc.strict_ieee && hw->fc.requested_mode == ixgbe_fc_rx_pause) {
+ hw_err(hw, "ixgbe_fc_rx_pause not valid in strict IEEE mode\n");
+ return IXGBE_ERR_INVALID_LINK_SETTINGS;
+ }
+
+ /* 10gig parts do not have a word in the EEPROM to determine the
+ * default flow control setting, so we explicitly set it to full.
+ */
+ if (hw->fc.requested_mode == ixgbe_fc_default)
+ hw->fc.requested_mode = ixgbe_fc_full;
+
+ /* Determine PAUSE and ASM_DIR bits. */
+ switch (hw->fc.requested_mode) {
+ case ixgbe_fc_none:
+ pause = false;
+ asm_dir = false;
+ break;
+ case ixgbe_fc_tx_pause:
+ pause = false;
+ asm_dir = true;
+ break;
+ case ixgbe_fc_rx_pause:
+ /* Rx Flow control is enabled and Tx Flow control is
+ * disabled by software override. Since there really
+ * isn't a way to advertise that we are capable of RX
+ * Pause ONLY, we will advertise that we support both
+ * symmetric and asymmetric Rx PAUSE, as such we fall
+ * through to the fc_full statement. Later, we will
+ * disable the adapter's ability to send PAUSE frames.
+ */
+ /* Fallthrough */
+ case ixgbe_fc_full:
+ pause = true;
+ asm_dir = true;
+ break;
+ default:
+ hw_err(hw, "Flow control param set incorrectly\n");
+ return IXGBE_ERR_CONFIG;
+ }
+
+ if (hw->device_id != IXGBE_DEV_ID_X550EM_X_KR)
+ return 0;
+
+ rc = ixgbe_read_iosf_sb_reg_x550(hw,
+ IXGBE_KRM_AN_CNTL_1(hw->bus.lan_id),
+ IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+ if (rc)
+ return rc;
+
+ reg_val &= ~(IXGBE_KRM_AN_CNTL_1_SYM_PAUSE |
+ IXGBE_KRM_AN_CNTL_1_ASM_PAUSE);
+ if (pause)
+ reg_val |= IXGBE_KRM_AN_CNTL_1_SYM_PAUSE;
+ if (asm_dir)
+ reg_val |= IXGBE_KRM_AN_CNTL_1_ASM_PAUSE;
+ rc = ixgbe_write_iosf_sb_reg_x550(hw,
+ IXGBE_KRM_AN_CNTL_1(hw->bus.lan_id),
+ IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+ /* This device does not fully support AN. */
+ hw->fc.disable_fc_autoneg = true;
+
+ return rc;
+}
+
/** ixgbe_enter_lplu_x550em - Transition to low power states
* @hw: pointer to hardware structure
*
@@ -2337,8 +2417,6 @@ static void ixgbe_release_swfw_sync_X550em(struct ixgbe_hw *hw, u32 mask)
.enable_rx_buff = &ixgbe_enable_rx_buff_generic, \
.get_thermal_sensor_data = NULL, \
.init_thermal_sensor_thresh = NULL, \
- .prot_autoc_read = &prot_autoc_read_generic, \
- .prot_autoc_write = &prot_autoc_write_generic, \
.enable_rx = &ixgbe_enable_rx_generic, \
.disable_rx = &ixgbe_disable_rx_x550, \
@@ -2354,6 +2432,9 @@ static const struct ixgbe_mac_operations mac_ops_X550 = {
.setup_sfp = NULL,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync_X540,
.release_swfw_sync = &ixgbe_release_swfw_sync_X540,
+ .prot_autoc_read = prot_autoc_read_generic,
+ .prot_autoc_write = prot_autoc_write_generic,
+ .setup_fc = ixgbe_setup_fc_generic,
};
static const struct ixgbe_mac_operations mac_ops_X550EM_x = {
@@ -2368,6 +2449,7 @@ static const struct ixgbe_mac_operations mac_ops_X550EM_x = {
.setup_sfp = ixgbe_setup_sfp_modules_X550em,
.acquire_swfw_sync = &ixgbe_acquire_swfw_sync_X550em,
.release_swfw_sync = &ixgbe_release_swfw_sync_X550em,
+ .setup_fc = NULL, /* defined later */
};
#define X550_COMMON_EEP \
--
2.5.5
^ permalink raw reply related
* [net-next v2 11/14] ixgbe: add a callback to set the maximum transmit bitrate
From: Jeff Kirsher @ 2016-04-05 0:59 UTC (permalink / raw)
To: davem
Cc: Rostislav Pehlivanov, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1459817945-144915-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit adds a callback which allows to adjust the maximum transmit
bitrate the card can output. This makes it possible to get a smooth
traffic instead of the default burst-y behaviour when trying to output
e.g. a video stream.
Much of the logic needed to get a correct bcnrc_val was taken from the
ixgbe_set_vf_rate_limit() function.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 31 ++++++++++++++++++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 1 +
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 0f007d9..115656c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1078,6 +1078,36 @@ static void ixgbe_tx_timeout_reset(struct ixgbe_adapter *adapter)
}
/**
+ * ixgbe_tx_maxrate - callback to set the maximum per-queue bitrate
+ **/
+static int ixgbe_tx_maxrate(struct net_device *netdev,
+ int queue_index, u32 maxrate)
+{
+ struct ixgbe_adapter *adapter = netdev_priv(netdev);
+ struct ixgbe_hw *hw = &adapter->hw;
+ u32 bcnrc_val = ixgbe_link_mbps(adapter);
+
+ if (!maxrate)
+ return 0;
+
+ /* Calculate the rate factor values to set */
+ bcnrc_val <<= IXGBE_RTTBCNRC_RF_INT_SHIFT;
+ bcnrc_val /= maxrate;
+
+ /* clear everything but the rate factor */
+ bcnrc_val &= IXGBE_RTTBCNRC_RF_INT_MASK |
+ IXGBE_RTTBCNRC_RF_DEC_MASK;
+
+ /* enable the rate scheduler */
+ bcnrc_val |= IXGBE_RTTBCNRC_RS_ENA;
+
+ IXGBE_WRITE_REG(hw, IXGBE_RTTDQSEL, queue_index);
+ IXGBE_WRITE_REG(hw, IXGBE_RTTBCNRC, bcnrc_val);
+
+ return 0;
+}
+
+/**
* ixgbe_clean_tx_irq - Reclaim resources after transmit completes
* @q_vector: structure containing interrupt and ring information
* @tx_ring: tx ring to clean
@@ -8807,6 +8837,7 @@ static const struct net_device_ops ixgbe_netdev_ops = {
.ndo_set_mac_address = ixgbe_set_mac,
.ndo_change_mtu = ixgbe_change_mtu,
.ndo_tx_timeout = ixgbe_tx_timeout,
+ .ndo_set_tx_maxrate = ixgbe_tx_maxrate,
.ndo_vlan_rx_add_vid = ixgbe_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = ixgbe_vlan_rx_kill_vid,
.ndo_do_ioctl = ixgbe_ioctl,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 4bc24963..adcf000 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -1398,7 +1398,7 @@ out:
return err;
}
-static int ixgbe_link_mbps(struct ixgbe_adapter *adapter)
+int ixgbe_link_mbps(struct ixgbe_adapter *adapter)
{
switch (adapter->link_speed) {
case IXGBE_LINK_SPEED_100_FULL:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
index dad9257..47e65e2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
@@ -44,6 +44,7 @@ void ixgbe_ping_all_vfs(struct ixgbe_adapter *adapter);
int ixgbe_ndo_set_vf_mac(struct net_device *netdev, int queue, u8 *mac);
int ixgbe_ndo_set_vf_vlan(struct net_device *netdev, int queue, u16 vlan,
u8 qos);
+int ixgbe_link_mbps(struct ixgbe_adapter *adapter);
int ixgbe_ndo_set_vf_bw(struct net_device *netdev, int vf, int min_tx_rate,
int max_tx_rate);
int ixgbe_ndo_set_vf_spoofchk(struct net_device *netdev, int vf, bool setting);
--
2.5.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox