* Re: [PATCH 0/3] Add Broadcom Omega SoC internal switch and phy
From: David Miller @ 2018-08-07 22:49 UTC (permalink / raw)
To: andrew
Cc: arun.parameswaran, f.fainelli, vivien.didelot, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <20180807180827.GH18350@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 7 Aug 2018 20:08:27 +0200
> On Tue, Aug 07, 2018 at 10:02:41AM -0700, Arun Parameswaran wrote:
>> Hi,
>>
>> The patchset is based on David Miller's "net-next" repo.
>>
>> The patches add support for the Broadcom Omega SoC's internal ethernet
>> switch and the internal gphy.
>>
>> The internal ethernet switch in the Omega is a b53 srab based switch.
>> The support for the switch is added to the b53 driver in the dsa
>> framework.
>>
>> The gphy support is added to the bcm7xxx driver.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Series applied.
^ permalink raw reply
* Re: [PATCH bpf-next 3/3] bpf: add sample for BPF_MAP_TYPE_QUEUE
From: Jakub Kicinski @ 2018-08-07 20:31 UTC (permalink / raw)
To: Mauricio Vasquez B; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <153356392410.6981.1290059578982921349.stgit@kernel>
On Mon, 06 Aug 2018 15:58:47 +0200, Mauricio Vasquez B wrote:
> @@ -109,6 +110,7 @@ xdpsock-objs := xdpsock_user.o
> xdp_fwd-objs := xdp_fwd_user.o
> task_fd_query-objs := bpf_load.o task_fd_query_user.o $(TRACE_HELPERS)
> xdp_sample_pkts-objs := xdp_sample_pkts_user.o $(TRACE_HELPERS)
> +test_queuemap-objs := bpf_load.o test_queuemap_user.o
>
> # Tell kbuild to always build the programs
> always := $(hostprogs-y)
nit: would you mind using libbpf instead of bpf_load.o ?
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] qed: Add Multi-TC RoCE support
From: David Miller @ 2018-08-07 20:22 UTC (permalink / raw)
To: denis.bolotin; +Cc: netdev
In-Reply-To: <20180807124810.17386-1-denis.bolotin@cavium.com>
From: Denis Bolotin <denis.bolotin@cavium.com>
Date: Tue, 7 Aug 2018 15:48:07 +0300
> Hi Dave,
> This patch series adds support for multiple concurrent traffic classes for RoCE.
> The first three patches enable the required parts of the driver to learn the TC
> configuration, and the last one makes use of it to enable the feature.
> Please consider applying this to net-next.
>
> V1->V2:
> -------
> Avoid allocation in qed_dcbx_get_priority_tc().
> Move qed_dcbx_get_priority_tc() out of CONFIG_DCB section since it doesn't call
> qed_dcbx_query_params() anymore.
>
> v2->V3:
> -------
> patch 1/3:
> qed_dcbx_get_priority_tc() always returns a valid TC by value. In error cases,
> it returns QED_DCBX_DEFAULT_TC (currently defined 0).
> patch 3/3:
> Cosmetic changes in qed_dev.c.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] tipc: fix an interrupt unsafe locking scenario
From: David Miller @ 2018-08-07 20:18 UTC (permalink / raw)
To: ying.xue; +Cc: netdev, jon.maloy, tipc-discussion
In-Reply-To: <1533628352-31928-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 7 Aug 2018 15:52:32 +0800
> Commit 9faa89d4ed9d ("tipc: make function tipc_net_finalize() thread
> safe") tries to make it thread safe to set node address, so it uses
> node_list_lock lock to serialize the whole process of setting node
> address in tipc_net_finalize(). But it causes the following interrupt
> unsafe locking scenario:
...
> When rhashtable_rehash_table() holds ht->lock on CPU0, it doesn't
> disable BH. So if an interrupt happens after the lock, it can create
> an inverse lock ordering between ht->lock and tn->node_list_lock. As
> a consequence, deadlock might happen.
>
> The reason causing the inverse lock ordering scenario above is because
> the initial purpose of node_list_lock is not designed to do the
> serialization of node address setting.
>
> As cmpxchg() can guarantee CAS (compare-and-swap) process is atomic,
> we use it to replace node_list_lock to ensure setting node address can
> be atomically finished. It turns out the potential deadlock can be
> avoided as well.
>
> Fixes: 9faa89d4ed9d ("tipc: make function tipc_net_finalize() thread safe")
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: allow to call netif_reset_xps_queues() under cpu_read_lock
From: David Miller @ 2018-08-07 20:15 UTC (permalink / raw)
To: avagin; +Cc: netdev, virtualization, avagin, amritha.nambiar, mst, jasowang
In-Reply-To: <20180807041454.18315-1-avagin@openvz.org>
From: Andrei Vagin <avagin@openvz.org>
Date: Mon, 6 Aug 2018 21:14:54 -0700
> This patch adds an ability to call __netif_set_xps_queue under
> cpu_read_lock().
Please don't add conditional locking using a boolean argument.
Simply wrap calls to __netif_set_xps_queue() with cpu read
lock held by the caller or similar.
^ permalink raw reply
* [net-next:master 479/480] drivers/net/ieee802154/mac802154_hwsim.c:409:17: sparse: incorrect type in assignment (different address spaces)
From: kbuild test robot @ 2018-08-07 20:03 UTC (permalink / raw)
To: Alexander Aring; +Cc: kbuild-all, netdev, Stefan Schmidt
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 1ba982806ce58baac44c52e6c7812245afad27c8
commit: c5d99d2b35dadebab2408bb10dcd50364eaaf9f4 [479/480] ieee802154: hwsim: fix rcu address annotation
reproduce:
# apt-get install sparse
git checkout c5d99d2b35dadebab2408bb10dcd50364eaaf9f4
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ieee802154/mac802154_hwsim.c:799:18: sparse: incorrect type in assignment (different address spaces) @@ expected struct hwsim_pib [noderef] <asn:4>*pib @@ got hwsim_pib [noderef] <asn:4>*pib @@
drivers/net/ieee802154/mac802154_hwsim.c:799:18: expected struct hwsim_pib [noderef] <asn:4>*pib
drivers/net/ieee802154/mac802154_hwsim.c:799:18: got struct hwsim_pib *[assigned] pib
drivers/net/ieee802154/mac802154_hwsim.c:835:9: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct callback_head *head @@ got struct callback_hstruct callback_head *head @@
drivers/net/ieee802154/mac802154_hwsim.c:835:9: expected struct callback_head *head
drivers/net/ieee802154/mac802154_hwsim.c:835:9: got struct callback_head [noderef] <asn:4>*<noident>
drivers/net/ieee802154/mac802154_hwsim.c:113:17: sparse: incorrect type in assignment (different address spaces) @@ expected struct hwsim_pib *pib_old @@ got struct hwsim_pib struct hwsim_pib *pib_old @@
drivers/net/ieee802154/mac802154_hwsim.c:113:17: expected struct hwsim_pib *pib_old
drivers/net/ieee802154/mac802154_hwsim.c:113:17: got struct hwsim_pib [noderef] <asn:4>*pib
>> drivers/net/ieee802154/mac802154_hwsim.c:409:17: sparse: incorrect type in assignment (different address spaces) @@ expected struct hwsim_edge_info [noderef] <asn:4>*info @@ got hwsim_edge_info [noderef] <asn:4>*info @@
drivers/net/ieee802154/mac802154_hwsim.c:409:17: expected struct hwsim_edge_info [noderef] <asn:4>*info
drivers/net/ieee802154/mac802154_hwsim.c:409:17: got struct hwsim_edge_info *[assigned] einfo
drivers/net/ieee802154/mac802154_hwsim.c:417:9: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct callback_head *head @@ got struct callback_hstruct callback_head *head @@
drivers/net/ieee802154/mac802154_hwsim.c:417:9: expected struct callback_head *head
drivers/net/ieee802154/mac802154_hwsim.c:417:9: got struct callback_head [noderef] <asn:4>*<noident>
vim +409 drivers/net/ieee802154/mac802154_hwsim.c
f25da51f Alexander Aring 2018-07-14 392
f25da51f Alexander Aring 2018-07-14 393 static struct hwsim_edge *hwsim_alloc_edge(struct hwsim_phy *endpoint, u8 lqi)
f25da51f Alexander Aring 2018-07-14 394 {
f25da51f Alexander Aring 2018-07-14 395 struct hwsim_edge_info *einfo;
f25da51f Alexander Aring 2018-07-14 396 struct hwsim_edge *e;
f25da51f Alexander Aring 2018-07-14 397
f25da51f Alexander Aring 2018-07-14 398 e = kzalloc(sizeof(*e), GFP_KERNEL);
f25da51f Alexander Aring 2018-07-14 399 if (!e)
f25da51f Alexander Aring 2018-07-14 400 return NULL;
f25da51f Alexander Aring 2018-07-14 401
f25da51f Alexander Aring 2018-07-14 402 einfo = kzalloc(sizeof(*einfo), GFP_KERNEL);
f25da51f Alexander Aring 2018-07-14 403 if (!einfo) {
f25da51f Alexander Aring 2018-07-14 404 kfree(e);
f25da51f Alexander Aring 2018-07-14 405 return NULL;
f25da51f Alexander Aring 2018-07-14 406 }
f25da51f Alexander Aring 2018-07-14 407
f25da51f Alexander Aring 2018-07-14 408 einfo->lqi = 0xff;
f25da51f Alexander Aring 2018-07-14 @409 e->info = einfo;
f25da51f Alexander Aring 2018-07-14 410 e->endpoint = endpoint;
f25da51f Alexander Aring 2018-07-14 411
f25da51f Alexander Aring 2018-07-14 412 return e;
f25da51f Alexander Aring 2018-07-14 413 }
f25da51f Alexander Aring 2018-07-14 414
:::::: The code at line 409 was first introduced by commit
:::::: f25da51fdc381ca2863248c7060b3662632f0872 ieee802154: hwsim: add replacement for fakelb
:::::: TO: Alexander Aring <aring@mojatatu.com>
:::::: CC: Stefan Schmidt <stefan@datenfreihafen.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: Is it currently possible to connect SFP to dsa port?
From: Andrew Lunn @ 2018-08-07 20:03 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Marek Behun, netdev, Russell King - ARM Linux
In-Reply-To: <2d62b88b-3a92-d026-effe-defcb9d5838b@gmail.com>
On Tue, Aug 07, 2018 at 12:43:11PM -0700, Florian Fainelli wrote:
>
>
> On 08/07/2018 12:00 PM, Marek Behun wrote:
> > Hello,
> >
> > I have a question regarding DSA/SFP code.
> >
> > We are working on a modular router where it is possible to connect
> > multiple switch cards and at most one SFP cage card to a router.
> >
> > Does the sfp/dsa driver support connecting SFP port to a DSA port? For
> > example the Marvell 6390 switch has two SGMII ports and 8 1Gbps PHYs.
> > One can then connect those 8 1Gbps PHYs to RJ-45 connectors, the first
> > SGMII port to the CPU and the second SGMII port to SFP.
> >
> > I think this is currently not possible, but am not sure.
>
> DSA recently gained support for PHYLINK which would allow you to do
> that, please make sure your tree has this commit at least:
>
> aab9c4067d2389d0adfc9c53806437df7b0fe3d5 ("net: dsa: Plug in PHYLINK
> support").
Hi Florian
That gives enough to not break existing setups using the mv88e6xxx
driver. But to really use PHYLINK, more code is needed. I've taken
some of Russell Kings work, and merged that in, which gives us proper
support for validate, config_mac, etc. But Russell's code is missing
calls to phylink_mac_change, and handling SERDES interfaces, which are
needed for SFPs. I've got some code which is near, but it broke D in
DSA on my board :-(
Andrew
^ permalink raw reply
* Re: Is it currently possible to connect SFP to dsa port?
From: Andrew Lunn @ 2018-08-07 19:58 UTC (permalink / raw)
To: Marek Behun; +Cc: netdev, Russell King - ARM Linux
In-Reply-To: <20180807210023.0dc3d498@nic.cz>
On Tue, Aug 07, 2018 at 09:00:23PM +0200, Marek Behun wrote:
> Hello,
>
> I have a question regarding DSA/SFP code.
>
> We are working on a modular router where it is possible to connect
> multiple switch cards and at most one SFP cage card to a router.
>
> Does the sfp/dsa driver support connecting SFP port to a DSA port? For
> example the Marvell 6390 switch has two SGMII ports and 8 1Gbps PHYs.
> One can then connect those 8 1Gbps PHYs to RJ-45 connectors, the first
> SGMII port to the CPU and the second SGMII port to SFP.
Hi Marek
I'm currently working on exactly this!
My primary aim is to allow SFP on ports 9 and 10. ports 2-7 can also
be connected to SFPs, but that is a bit harder, so it is going to take
me a little longer.
I hope i can post patches in the next few days.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/2] ibmvnic: Update firmware error reporting
From: David Miller @ 2018-08-07 19:46 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, jallen, nfont
In-Reply-To: <1533609599-10188-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Mon, 6 Aug 2018 21:39:57 -0500
> This patch set cleans out a lot of dead code from the ibmvnic driver
> and adds some more. The error ID field of the descriptor is not filled
> in by firmware, so do not print it and do not use it to query for
> more detailed information. Remove the unused code written for this.
> Finally, update the message to print a string explainng the error
> cause instead of just the error code.
Series applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
From: Andy Lutomirski @ 2018-08-07 19:43 UTC (permalink / raw)
To: Jason A. Donenfeld, Ingo Molnar, Thomas Gleixner, linux-arch
Cc: Eric Biggers, Linux Crypto Mailing List, LKML, Netdev,
David Miller, Andrew Lutomirski, Greg Kroah-Hartman, Samuel Neves,
Daniel J . Bernstein, Tanja Lange, Jean-Philippe Aumasson,
Karthikeyan Bhargavan
In-Reply-To: <CAHmME9rA_nb9Le4VQhtcqCfNSuHpFjZVOV6=vE12FydJD9CmAQ@mail.gmail.com>
On Tue, Aug 7, 2018 at 11:54 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hey Andy, Eric, & all,
>
> I've started the work of separating this out into 16 individual
> commits, have addressed numerous other things brought up like the
> ifdef maze, and have begun rewriting (parts of) the original commit
> message. It's still a work in progress, and I still have some work to
> do, but if you want to follow along, things are happening here:
>
> https://git.zx2c4.com/linux-dev/log/?h=jd/wireguard
>
> I'll be rebasing and reworking this continuously, but that's how it's
> shaping up.
>
> As I'm still working on it, I won't be submitting v2 today, but if you
> have suggestions or concerns or want to poke me while I'm working on
> v2, don't hesitate to send me private email or ping me in IRC (I'm
> "zx2c4" there) to chat.
>
> Regards,
> Jason
For "zinc: add simd helper", I think it should be in include/linux,
and include/linux/simd.h should (immediately or maybe in the future)
include <asm/simd.h> to pick up arch-specific stuff. And the patch
should get sent to linux-arch@vger.kernel.org.
In your blake2s_arch() implementation, you're not passing in a
simd_context_t. Is that still a work in progress? I thought the plan
was to pass it in rather than doing the check in the _arch()
functions.
^ permalink raw reply
* Re: Is it currently possible to connect SFP to dsa port?
From: Florian Fainelli @ 2018-08-07 19:43 UTC (permalink / raw)
To: Marek Behun, Andrew Lunn; +Cc: netdev, Russell King - ARM Linux
In-Reply-To: <20180807210023.0dc3d498@nic.cz>
On 08/07/2018 12:00 PM, Marek Behun wrote:
> Hello,
>
> I have a question regarding DSA/SFP code.
>
> We are working on a modular router where it is possible to connect
> multiple switch cards and at most one SFP cage card to a router.
>
> Does the sfp/dsa driver support connecting SFP port to a DSA port? For
> example the Marvell 6390 switch has two SGMII ports and 8 1Gbps PHYs.
> One can then connect those 8 1Gbps PHYs to RJ-45 connectors, the first
> SGMII port to the CPU and the second SGMII port to SFP.
>
> I think this is currently not possible, but am not sure.
DSA recently gained support for PHYLINK which would allow you to do
that, please make sure your tree has this commit at least:
aab9c4067d2389d0adfc9c53806437df7b0fe3d5 ("net: dsa: Plug in PHYLINK
support").
--
Florian
^ permalink raw reply
* [Patch net] llc: use refcount_inc_not_zero() for llc_sap_find()
From: Cong Wang @ 2018-08-07 19:41 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang
llc_sap_put() decreases the refcnt before deleting sap
from the global list. Therefore, there is a chance
llc_sap_find() could find a sap with zero refcnt
in this global list.
Close this race condition by checking if refcnt is zero
or not in llc_sap_find(), if it is zero then it is being
removed so we can just treat it as gone.
Reported-by: <syzbot+278893f3f7803871f7ce@syzkaller.appspotmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
include/net/llc.h | 5 +++++
net/llc/llc_core.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/net/llc.h b/include/net/llc.h
index dc35f25eb679..890a87318014 100644
--- a/include/net/llc.h
+++ b/include/net/llc.h
@@ -116,6 +116,11 @@ static inline void llc_sap_hold(struct llc_sap *sap)
refcount_inc(&sap->refcnt);
}
+static inline bool llc_sap_hold_safe(struct llc_sap *sap)
+{
+ return refcount_inc_not_zero(&sap->refcnt);
+}
+
void llc_sap_close(struct llc_sap *sap);
static inline void llc_sap_put(struct llc_sap *sap)
diff --git a/net/llc/llc_core.c b/net/llc/llc_core.c
index 89041260784c..260b3dc1b4a2 100644
--- a/net/llc/llc_core.c
+++ b/net/llc/llc_core.c
@@ -73,8 +73,8 @@ struct llc_sap *llc_sap_find(unsigned char sap_value)
rcu_read_lock_bh();
sap = __llc_sap_find(sap_value);
- if (sap)
- llc_sap_hold(sap);
+ if (!sap || !llc_sap_hold_safe(sap))
+ sap = NULL;
rcu_read_unlock_bh();
return sap;
}
--
2.14.4
^ permalink raw reply related
* Re: [PATCH net-next] liquidio: avoided acquiring post_lock for data only queues
From: David Miller @ 2018-08-07 19:41 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20180806200940.GA2501@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Mon, 6 Aug 2018 13:09:40 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> All control commands (soft commands) goes through only Queue 0
> (control and data queue). So only queue-0 needs post_lock,
> other queues are only data queues and does not need post_lock
>
> Added a flag to indicate the queue can be used for soft commands.
>
> If this flag is set, post_lock must be acquired before posting
> a command to the queue.
> If this flag is clear, post_lock is invalid for the queue.
>
> Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied, thank you.
^ permalink raw reply
* Re: [Patch net] vsock: split dwork to avoid reinitializations
From: David Miller @ 2018-08-07 19:39 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, acking, stefanha, jhansen
In-Reply-To: <20180806180602.6438-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 6 Aug 2018 11:06:02 -0700
> syzbot reported that we reinitialize an active delayed
> work in vsock_stream_connect():
>
> ODEBUG: init active (active state 0) object type: timer_list hint:
> delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:1414
> WARNING: CPU: 1 PID: 11518 at lib/debugobjects.c:329
> debug_print_object+0x16a/0x210 lib/debugobjects.c:326
>
> The pattern is apparently wrong, we should only initialize
> the dealyed work once and could repeatly schedule it. So we
> have to move out the initializations to allocation side.
> And to avoid confusion, we can split the shared dwork
> into two, instead of re-using the same one.
>
> Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
> Reported-by: <syzbot+8a9b1bd330476a4f3db6@syzkaller.appspotmail.com>
> Cc: Andy king <acking@vmware.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Jorgen Hansen <jhansen@vmware.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ip6_tunnel: collect_md xmit: Use ip_tunnel_key's provided src address
From: David Miller @ 2018-08-07 19:37 UTC (permalink / raw)
To: shmulik; +Cc: ast, netdev, shmulik.ladkani
In-Reply-To: <20180806120059.24992-1-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik@metanetworks.com>
Date: Mon, 6 Aug 2018 15:00:59 +0300
> When using an ip6tnl device in collect_md mode, the xmit methods ignore
> the ipv6.src field present in skb_tunnel_info's key, both for route
> calculation purposes (flowi6 construction) and for assigning the
> packet's final ipv6h->saddr.
>
> This makes it impossible specifying a desired ipv6 local address in the
> encapsulating header (for example, when using tc action tunnel_key).
>
> This is also not aligned with behavior of ipip (ipv4) in collect_md
> mode, where the key->u.ipv4.src gets used.
>
> Fix, by assigning fl6.saddr with given key->u.ipv6.src.
> In case ipv6.src is not specified, ip6_tnl_xmit uses existing saddr
> selection code.
Applied, thanks.
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
> Reviewed-by: Eyal Birger <eyal.birger@gmail.com>
> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
Please place the Fixes: tag first in the set of tags in the future,
thank you.
^ permalink raw reply
* Re: [PATCH net-next-internal] net: sched: cls_flower: set correct offload data in fl_reoffload
From: David Miller @ 2018-08-07 19:36 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <1533544030-26436-1-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 6 Aug 2018 11:27:10 +0300
> fl_reoffload implementation sets following members of struct
> tc_cls_flower_offload incorrectly:
> - masked key instead of mask
> - key instead of masked key
>
> Fix fl_reoffload to provide correct data to offload callback.
>
> Fixes: 31533cba4327 ("net: sched: cls_flower: implement offload tcf_proto_op")
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [endianness bug] cxgb4: mk_act_open_req() buggers ->{local,peer}_ip on big-endian hosts
From: David Miller @ 2018-08-07 19:35 UTC (permalink / raw)
To: viro; +Cc: kumaras, rahul.lakkireddy, netdev
In-Reply-To: <20180805172238.GH15082@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Sun, 5 Aug 2018 18:22:38 +0100
> Unlike fs.val.lport and fs.val.fport, cxgb4_process_flow_match()
> sets fs.val.{l,f}ip to net-endian values without conversion - they come
> straight from flow_dissector_key_ipv4_addrs ->dst and ->src resp. So
> the assignment in mk_act_open_req() ought to be a straigh copy.
>
> As far as I know, T4 PCIe cards do exist, so it's not as if that
> thing could only be found on little-endian systems...
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Applied.
^ permalink raw reply
* [net-next 03/12] i40e: add helper function for copying strings from stat arrays
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Many of the ethtool statistics use the same basic logic for copying
strings into the supplied buffer. A set of stats are stored in a const
array of i40e_stats structures, and we apply these all together.
Simplify the stats code by introducing a helper function which can take
a stats array and copy the strings into the buffer, updating the buffer
pointer as we go.
We use a macro to implement i40e_add_stat_strings so that ARRAY_SIZE can
be used on the array passed in. This ensures that we always use the
matching size in __i40e_add_stat_strings.
More complex stats currently do not use i40e_stats arrays, usually due
to custom formatted strings, or because the stats are not laid out in
the expected way. These stats will be updated to use the helper function
in separate future patches.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/i40e/i40e_ethtool.c | 59 ++++++++++++-------
1 file changed, 39 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 6947a2a571cb..20e86304e346 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1815,6 +1815,37 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
*(data++) = pf->stats.priority_xon_2_xoff[i];
}
+/**
+ * __i40e_add_stat_strings - copy stat strings into ethtool buffer
+ * @p: ethtool supplied buffer
+ * @stats: stat definitions array
+ * @size: size of the stats array
+ *
+ * Copy the strings described by stats into the buffer pointed at by p.
+ **/
+static void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
+ const unsigned int size)
+{
+ unsigned int i;
+
+ for (i = 0; i < size; i++) {
+ snprintf(*p, ETH_GSTRING_LEN, "%s", stats[i].stat_string);
+ *p += ETH_GSTRING_LEN;
+ }
+}
+
+/**
+ * 40e_add_stat_strings - copy stat strings into ethtool buffer
+ * @p: ethtool supplied buffer
+ * @stats: stat definitions array
+ *
+ * Format and copy the strings described by the const static stats value into
+ * the buffer pointed at by p. Assumes that stats can have ARRAY_SIZE called
+ * for it.
+ **/
+#define i40e_add_stat_strings(p, stats, ...) \
+ __i40e_add_stat_strings(p, stats, ARRAY_SIZE(stats))
+
/**
* i40e_get_stat_strings - copy stat strings into supplied buffer
* @netdev: the netdev to collect strings for
@@ -1833,16 +1864,10 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
unsigned int i;
u8 *p = data;
- for (i = 0; i < I40E_NETDEV_STATS_LEN; i++) {
- snprintf(data, ETH_GSTRING_LEN, "%s",
- i40e_gstrings_net_stats[i].stat_string);
- data += ETH_GSTRING_LEN;
- }
- for (i = 0; i < I40E_MISC_STATS_LEN; i++) {
- snprintf(data, ETH_GSTRING_LEN, "%s",
- i40e_gstrings_misc_stats[i].stat_string);
- data += ETH_GSTRING_LEN;
- }
+ i40e_add_stat_strings(&data, i40e_gstrings_net_stats);
+
+ i40e_add_stat_strings(&data, i40e_gstrings_misc_stats);
+
for (i = 0; i < I40E_MAX_NUM_QUEUES(netdev); i++) {
snprintf(data, ETH_GSTRING_LEN, "tx-%u.tx_packets", i);
data += ETH_GSTRING_LEN;
@@ -1856,11 +1881,8 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
if (vsi != pf->vsi[pf->lan_vsi] || pf->hw.partition_id != 1)
return;
- for (i = 0; i < I40E_VEB_STATS_LEN; i++) {
- snprintf(data, ETH_GSTRING_LEN, "%s",
- i40e_gstrings_veb_stats[i].stat_string);
- data += ETH_GSTRING_LEN;
- }
+ i40e_add_stat_strings(&data, i40e_gstrings_veb_stats);
+
for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
snprintf(data, ETH_GSTRING_LEN,
"veb.tc_%u_tx_packets", i);
@@ -1876,11 +1898,8 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
data += ETH_GSTRING_LEN;
}
- for (i = 0; i < I40E_GLOBAL_STATS_LEN; i++) {
- snprintf(data, ETH_GSTRING_LEN, "%s",
- i40e_gstrings_stats[i].stat_string);
- data += ETH_GSTRING_LEN;
- }
+ i40e_add_stat_strings(&data, i40e_gstrings_stats);
+
for (i = 0; i < I40E_MAX_USER_PRIORITY; i++) {
snprintf(data, ETH_GSTRING_LEN,
"port.tx_priority_%u_xon", i);
--
2.17.1
^ permalink raw reply related
* [net-next 11/12] i40e: Add AQ command for rearrange NVM structure
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Piotr Azarewicz, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Piotr Azarewicz <piotr.azarewicz@intel.com>
During switching between old NVM structure approach (called structured
NVM) to new one (called flat NVM) or backward flash needs to be
rearranged to required NVM structure. This is a part of transition from
one NVM structure to another. The function is introduced to command
firmware to start rearrangement process.
Signed-off-by: Piotr Azarewicz <piotr.azarewicz@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/i40e/i40e_adminq_cmd.h | 2 ++
drivers/net/ethernet/intel/i40e/i40e_common.c | 35 +++++++++++++++++++
.../net/ethernet/intel/i40e/i40e_prototype.h | 3 ++
.../ethernet/intel/i40evf/i40e_adminq_cmd.h | 2 ++
4 files changed, 42 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
index 7d888e05f96f..80e3eec6134e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
@@ -2247,6 +2247,8 @@ I40E_CHECK_CMD_LENGTH(i40e_aqc_phy_register_access);
struct i40e_aqc_nvm_update {
u8 command_flags;
#define I40E_AQ_NVM_LAST_CMD 0x01
+#define I40E_AQ_NVM_REARRANGE_TO_FLAT 0x20
+#define I40E_AQ_NVM_REARRANGE_TO_STRUCT 0x40
#define I40E_AQ_NVM_FLASH_ONLY 0x80
#define I40E_AQ_NVM_PRESERVATION_FLAGS_SHIFT 1
#define I40E_AQ_NVM_PRESERVATION_FLAGS_MASK 0x03
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c b/drivers/net/ethernet/intel/i40e/i40e_common.c
index eb2d1530d331..85f75b5978fc 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -3540,6 +3540,41 @@ i40e_status i40e_aq_update_nvm(struct i40e_hw *hw, u8 module_pointer,
return status;
}
+/**
+ * i40e_aq_rearrange_nvm
+ * @hw: pointer to the hw struct
+ * @rearrange_nvm: defines direction of rearrangement
+ * @cmd_details: pointer to command details structure or NULL
+ *
+ * Rearrange NVM structure, available only for transition FW
+ **/
+i40e_status i40e_aq_rearrange_nvm(struct i40e_hw *hw,
+ u8 rearrange_nvm,
+ struct i40e_asq_cmd_details *cmd_details)
+{
+ struct i40e_aqc_nvm_update *cmd;
+ i40e_status status;
+ struct i40e_aq_desc desc;
+
+ cmd = (struct i40e_aqc_nvm_update *)&desc.params.raw;
+
+ i40e_fill_default_direct_cmd_desc(&desc, i40e_aqc_opc_nvm_update);
+
+ rearrange_nvm &= (I40E_AQ_NVM_REARRANGE_TO_FLAT |
+ I40E_AQ_NVM_REARRANGE_TO_STRUCT);
+
+ if (!rearrange_nvm) {
+ status = I40E_ERR_PARAM;
+ goto i40e_aq_rearrange_nvm_exit;
+ }
+
+ cmd->command_flags |= rearrange_nvm;
+ status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
+
+i40e_aq_rearrange_nvm_exit:
+ return status;
+}
+
/**
* i40e_aq_get_lldp_mib
* @hw: pointer to the hw struct
diff --git a/drivers/net/ethernet/intel/i40e/i40e_prototype.h b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
index 3170655cdeb9..e08d754824b1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_prototype.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
@@ -193,6 +193,9 @@ i40e_status i40e_aq_update_nvm(struct i40e_hw *hw, u8 module_pointer,
u32 offset, u16 length, void *data,
bool last_command, u8 preservation_flags,
struct i40e_asq_cmd_details *cmd_details);
+i40e_status i40e_aq_rearrange_nvm(struct i40e_hw *hw,
+ u8 rearrange_nvm,
+ struct i40e_asq_cmd_details *cmd_details);
i40e_status i40e_aq_get_lldp_mib(struct i40e_hw *hw, u8 bridge_type,
u8 mib_type, void *buff, u16 buff_size,
u16 *local_len, u16 *remote_len,
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
index aa81e87cd471..5fd8529465d4 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
@@ -2175,6 +2175,8 @@ I40E_CHECK_CMD_LENGTH(i40e_aqc_phy_register_access);
struct i40e_aqc_nvm_update {
u8 command_flags;
#define I40E_AQ_NVM_LAST_CMD 0x01
+#define I40E_AQ_NVM_REARRANGE_TO_FLAT 0x20
+#define I40E_AQ_NVM_REARRANGE_TO_STRUCT 0x40
#define I40E_AQ_NVM_FLASH_ONLY 0x80
#define I40E_AQ_NVM_PRESERVATION_FLAGS_SHIFT 1
#define I40E_AQ_NVM_PRESERVATION_FLAGS_MASK 0x03
--
2.17.1
^ permalink raw reply related
* [net-next 04/12] i40e: add helper to copy statistic values into ethtool buffer
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Similar to the helper function to copy the ethtool stats strings, add
and use a helper function for copying the ethtool stats into the
supplied buffer.
Just like before, we use a macro to avoid having to pass ARRAY_SIZE
manually, so as to reduce chance of bugs.
Some of the stats, especially queue stats, are a bit trickier, and will
be handled in future patches.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/i40e/i40e_ethtool.c | 116 ++++++++++++++----
1 file changed, 93 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 20e86304e346..c051afe98b49 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1705,6 +1705,89 @@ static int i40e_get_sset_count(struct net_device *netdev, int sset)
}
}
+/**
+ * i40e_add_one_ethtool_stat - copy the stat into the supplied buffer
+ * @data: location to store the stat value
+ * @pointer: basis for where to copy from
+ * @stat: the stat definition
+ *
+ * Copies the stat data defined by the pointer and stat structure pair into
+ * the memory supplied as data. Used to implement i40e_add_ethtool_stats.
+ * If the pointer is null, data will be zero'd.
+ */
+static inline void
+i40e_add_one_ethtool_stat(u64 *data, void *pointer,
+ const struct i40e_stats *stat)
+{
+ char *p;
+
+ if (!pointer) {
+ /* ensure that the ethtool data buffer is zero'd for any stats
+ * which don't have a valid pointer.
+ */
+ *data = 0;
+ return;
+ }
+
+ p = (char *)pointer + stat->stat_offset;
+ switch (stat->sizeof_stat) {
+ case sizeof(u64):
+ *data = *((u64 *)p);
+ break;
+ case sizeof(u32):
+ *data = *((u32 *)p);
+ break;
+ case sizeof(u16):
+ *data = *((u16 *)p);
+ break;
+ case sizeof(u8):
+ *data = *((u8 *)p);
+ break;
+ default:
+ WARN_ONCE(1, "unexpected stat size for %s",
+ stat->stat_string);
+ *data = 0;
+ }
+}
+
+/**
+ * __i40e_add_ethtool_stats - copy stats into the ethtool supplied buffer
+ * @data: ethtool stats buffer
+ * @pointer: location to copy stats from
+ * @stats: array of stats to copy
+ * @size: the size of the stats definition
+ *
+ * Copy the stats defined by the stats array using the pointer as a base into
+ * the data buffer supplied by ethtool. Updates the data pointer to point to
+ * the next empty location for successive calls to __i40e_add_ethtool_stats.
+ * If pointer is null, set the data values to zero and update the pointer to
+ * skip these stats.
+ **/
+static inline void
+__i40e_add_ethtool_stats(u64 **data, void *pointer,
+ const struct i40e_stats stats[],
+ const unsigned int size)
+{
+ unsigned int i;
+
+ for (i = 0; i < size; i++)
+ i40e_add_one_ethtool_stat((*data)++, pointer, &stats[i]);
+}
+
+/**
+ * i40e_add_ethtool_stats - copy stats into ethtool supplied buffer
+ * @data: ethtool stats buffer
+ * @pointer: location where stats are stored
+ * @stats: static const array of stat definitions
+ *
+ * Macro to ease the use of __i40e_add_ethtool_stats by taking a static
+ * constant stats array and passing the ARRAY_SIZE(). This avoids typos by
+ * ensuring that we pass the size associated with the given stats array.
+ * Assumes that stats is an array.
+ **/
+#define i40e_add_ethtool_stats(data, pointer, stats) \
+ __i40e_add_ethtool_stats(data, pointer, stats, ARRAY_SIZE(stats))
+
/**
* i40e_get_ethtool_stats - copy stat values into supplied buffer
* @netdev: the netdev to collect stats for
@@ -1727,22 +1810,15 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
struct i40e_vsi *vsi = np->vsi;
struct i40e_pf *pf = vsi->back;
unsigned int i;
- char *p;
- struct rtnl_link_stats64 *net_stats = i40e_get_vsi_stats_struct(vsi);
unsigned int start;
i40e_update_stats(vsi);
- for (i = 0; i < I40E_NETDEV_STATS_LEN; i++) {
- p = (char *)net_stats + i40e_gstrings_net_stats[i].stat_offset;
- *(data++) = (i40e_gstrings_net_stats[i].sizeof_stat ==
- sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
- }
- for (i = 0; i < I40E_MISC_STATS_LEN; i++) {
- p = (char *)vsi + i40e_gstrings_misc_stats[i].stat_offset;
- *(data++) = (i40e_gstrings_misc_stats[i].sizeof_stat ==
- sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
- }
+ i40e_add_ethtool_stats(&data, i40e_get_vsi_stats_struct(vsi),
+ i40e_gstrings_net_stats);
+
+ i40e_add_ethtool_stats(&data, vsi, i40e_gstrings_misc_stats);
+
rcu_read_lock();
for (i = 0; i < I40E_MAX_NUM_QUEUES(netdev) ; i++) {
tx_ring = READ_ONCE(vsi->tx_rings[i]);
@@ -1783,12 +1859,8 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
(pf->flags & I40E_FLAG_VEB_STATS_ENABLED)) {
struct i40e_veb *veb = pf->veb[pf->lan_veb];
- for (i = 0; i < I40E_VEB_STATS_LEN; i++) {
- p = (char *)veb;
- p += i40e_gstrings_veb_stats[i].stat_offset;
- *(data++) = (i40e_gstrings_veb_stats[i].sizeof_stat ==
- sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
- }
+ i40e_add_ethtool_stats(&data, veb, i40e_gstrings_veb_stats);
+
for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
*(data++) = veb->tc_stats.tc_tx_packets[i];
*(data++) = veb->tc_stats.tc_tx_bytes[i];
@@ -1798,11 +1870,9 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
} else {
data += I40E_VEB_STATS_TOTAL;
}
- for (i = 0; i < I40E_GLOBAL_STATS_LEN; i++) {
- p = (char *)pf + i40e_gstrings_stats[i].stat_offset;
- *(data++) = (i40e_gstrings_stats[i].sizeof_stat ==
- sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
- }
+
+ i40e_add_ethtool_stats(&data, pf, i40e_gstrings_stats);
+
for (i = 0; i < I40E_MAX_USER_PRIORITY; i++) {
*(data++) = pf->stats.priority_xon_tx[i];
*(data++) = pf->stats.priority_xoff_tx[i];
--
2.17.1
^ permalink raw reply related
* [net-next 12/12] i40e: fix i40e_add_queue_stats data pointer update
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
This function accidentally failed to update the data pointer, which
caused the reported stats to be incorrect. Additionally, statistics
which follow queue stats in the output would potentially read non-zeroed
garbage data from the ethtool buffer.
This occurred because the data double pointer was not dereferenced
before incrementing the size.
Additionally, make sure this issue is more visible by adding a WARN_ONCE
to the i40e_get_ethtool_stats function. This warning will trigger
whenever the data pointer is not at the expected address, similar to the
check that we make in the i40e_get_stat_strings() function.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index cd23d1e169c2..abcd096ede14 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1860,6 +1860,7 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
unsigned int i;
unsigned int start;
bool veb_stats;
+ u64 *p = data;
i40e_update_stats(vsi);
@@ -1902,7 +1903,7 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
}
rcu_read_unlock();
if (vsi != pf->vsi[pf->lan_vsi] || pf->hw.partition_id != 1)
- return;
+ goto check_data_pointer;
veb_stats = ((pf->lan_veb != I40E_NO_VEB) &&
(pf->flags & I40E_FLAG_VEB_STATS_ENABLED));
@@ -1925,6 +1926,10 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
i40e_add_ethtool_stats(&data, &pfc, i40e_gstrings_pfc_stats);
}
+
+check_data_pointer:
+ WARN_ONCE(data - p != i40e_get_stats_count(netdev),
+ "ethtool stats count mismatch!");
}
/**
--
2.17.1
^ permalink raw reply related
* [net-next 07/12] i40e: convert priority flow control stats to use helpers
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The priority flow control statistics are laid out in the stats structure
using arrays. This made it unwieldy to use as part of an i40e_stats
array.
Add a new structure type, i40e_pfc_stats, and a helper function
i40e_get_pfc_stats which can return the stats for a given priority
value as an i40e_pfc_stats structure.
Use this to create an i40e_stats array, which we'll use to format and
copy the strings and stats into the supplied buffers.
This reduces even more boiler plate code in i40e_get_ethtool_stats and
i40e_get_stat_strings.
An alternative would be to modify the structure definition for the pfc
stats, but this is more invasive to the rest of the code base.
Note that a macro was used to setup the copy of stats from the
pf->stats, as this reduces the chance of typos in the code names. It
will produce a checkpatch.pl warning due to re-use of a macro argument.
In this case, it should be safe, as the macro will fail to compile in
cases where the argument is not a simple structure member name, and thus
arguments with side effects should not be an issue.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/i40e/i40e_ethtool.c | 87 +++++++++++--------
1 file changed, 51 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 52ccafe1d257..9c380c0b0202 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -31,6 +31,8 @@ struct i40e_stats {
I40E_STAT(struct i40e_vsi, _name, _stat)
#define I40E_VEB_STAT(_name, _stat) \
I40E_STAT(struct i40e_veb, _name, _stat)
+#define I40E_PFC_STAT(_name, _stat) \
+ I40E_STAT(struct i40e_pfc_stats, _name, _stat)
static const struct i40e_stats i40e_gstrings_net_stats[] = {
I40E_NETDEV_STAT(rx_packets),
@@ -153,6 +155,22 @@ static const struct i40e_stats i40e_gstrings_stats[] = {
I40E_PF_STAT("port.rx_lpi_count", stats.rx_lpi_count),
};
+struct i40e_pfc_stats {
+ u64 priority_xon_rx;
+ u64 priority_xoff_rx;
+ u64 priority_xon_tx;
+ u64 priority_xoff_tx;
+ u64 priority_xon_2_xoff;
+};
+
+static const struct i40e_stats i40e_gstrings_pfc_stats[] = {
+ I40E_PFC_STAT("port.tx_priority_%u_xon_tx", priority_xon_tx),
+ I40E_PFC_STAT("port.tx_priority_%u_xoff_tx", priority_xoff_tx),
+ I40E_PFC_STAT("port.rx_priority_%u_xon_rx", priority_xon_rx),
+ I40E_PFC_STAT("port.rx_priority_%u_xoff_rx", priority_xoff_rx),
+ I40E_PFC_STAT("port.rx_priority_%u_xon_2_xoff", priority_xon_2_xoff),
+};
+
/* We use num_tx_queues here as a proxy for the maximum number of queues
* available because we always allocate queues symmetrically.
*/
@@ -167,13 +185,9 @@ static const struct i40e_stats i40e_gstrings_stats[] = {
#define I40E_VSI_STATS_LEN(n) (I40E_NETDEV_STATS_LEN + \
I40E_MISC_STATS_LEN + \
I40E_QUEUE_STATS_LEN((n)))
-#define I40E_PFC_STATS_LEN ( \
- (FIELD_SIZEOF(struct i40e_pf, stats.priority_xoff_rx) + \
- FIELD_SIZEOF(struct i40e_pf, stats.priority_xon_rx) + \
- FIELD_SIZEOF(struct i40e_pf, stats.priority_xoff_tx) + \
- FIELD_SIZEOF(struct i40e_pf, stats.priority_xon_tx) + \
- FIELD_SIZEOF(struct i40e_pf, stats.priority_xon_2_xoff)) \
- / sizeof(u64))
+
+#define I40E_PFC_STATS_LEN (ARRAY_SIZE(i40e_gstrings_pfc_stats) * \
+ I40E_MAX_USER_PRIORITY)
#define I40E_VEB_STATS_LEN (ARRAY_SIZE(i40e_gstrings_veb_stats) + \
(ARRAY_SIZE(i40e_gstrings_veb_tc_stats) * \
@@ -1798,6 +1812,31 @@ __i40e_add_ethtool_stats(u64 **data, void *pointer,
#define i40e_add_ethtool_stats(data, pointer, stats) \
__i40e_add_ethtool_stats(data, pointer, stats, ARRAY_SIZE(stats))
+/**
+ * i40e_get_pfc_stats - copy HW PFC statistics to formatted structure
+ * @pf: the PF device structure
+ * @i: the priority value to copy
+ *
+ * The PFC stats are found as arrays in pf->stats, which is not easy to pass
+ * into i40e_add_ethtool_stats. Produce a formatted i40e_pfc_stats structure
+ * of the PFC stats for the given priority.
+ **/
+static inline struct i40e_pfc_stats
+i40e_get_pfc_stats(struct i40e_pf *pf, unsigned int i)
+{
+#define I40E_GET_PFC_STAT(stat, priority) \
+ .stat = pf->stats.stat[priority]
+
+ struct i40e_pfc_stats pfc = {
+ I40E_GET_PFC_STAT(priority_xon_rx, i),
+ I40E_GET_PFC_STAT(priority_xoff_rx, i),
+ I40E_GET_PFC_STAT(priority_xon_tx, i),
+ I40E_GET_PFC_STAT(priority_xoff_tx, i),
+ I40E_GET_PFC_STAT(priority_xon_2_xoff, i),
+ };
+ return pfc;
+}
+
/**
* i40e_get_ethtool_stats - copy stat values into supplied buffer
* @netdev: the netdev to collect stats for
@@ -1884,15 +1923,10 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
i40e_add_ethtool_stats(&data, pf, i40e_gstrings_stats);
for (i = 0; i < I40E_MAX_USER_PRIORITY; i++) {
- *(data++) = pf->stats.priority_xon_tx[i];
- *(data++) = pf->stats.priority_xoff_tx[i];
- }
- for (i = 0; i < I40E_MAX_USER_PRIORITY; i++) {
- *(data++) = pf->stats.priority_xon_rx[i];
- *(data++) = pf->stats.priority_xoff_rx[i];
+ struct i40e_pfc_stats pfc = i40e_get_pfc_stats(pf, i);
+
+ i40e_add_ethtool_stats(&data, &pfc, i40e_gstrings_pfc_stats);
}
- for (i = 0; i < I40E_MAX_USER_PRIORITY; i++)
- *(data++) = pf->stats.priority_xon_2_xoff[i];
}
/**
@@ -1973,27 +2007,8 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
i40e_add_stat_strings(&data, i40e_gstrings_stats);
- for (i = 0; i < I40E_MAX_USER_PRIORITY; i++) {
- snprintf(data, ETH_GSTRING_LEN,
- "port.tx_priority_%u_xon", i);
- data += ETH_GSTRING_LEN;
- snprintf(data, ETH_GSTRING_LEN,
- "port.tx_priority_%u_xoff", i);
- data += ETH_GSTRING_LEN;
- }
- for (i = 0; i < I40E_MAX_USER_PRIORITY; i++) {
- snprintf(data, ETH_GSTRING_LEN,
- "port.rx_priority_%u_xon", i);
- data += ETH_GSTRING_LEN;
- snprintf(data, ETH_GSTRING_LEN,
- "port.rx_priority_%u_xoff", i);
- data += ETH_GSTRING_LEN;
- }
- for (i = 0; i < I40E_MAX_USER_PRIORITY; i++) {
- snprintf(data, ETH_GSTRING_LEN,
- "port.rx_priority_%u_xon_2_xoff", i);
- data += ETH_GSTRING_LEN;
- }
+ for (i = 0; i < I40E_MAX_USER_PRIORITY; i++)
+ i40e_add_stat_strings(&data, i40e_gstrings_pfc_stats, i);
WARN_ONCE(p - data != i40e_get_stats_count(netdev) * ETH_GSTRING_LEN,
"stat strings count mismatch!");
--
2.17.1
^ permalink raw reply related
* [net-next 10/12] i40e: Add additional return code to i40e_asq_send_command
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Piotr Azarewicz, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Piotr Azarewicz <piotr.azarewicz@intel.com>
Firmware can return a busy state, so the function return
I40E_ERR_NOT_READY.
Signed-off-by: Piotr Azarewicz <piotr.azarewicz@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 2 ++
drivers/net/ethernet/intel/i40evf/i40e_adminq.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.c b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
index ddbea79d18e5..501ee718177f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
@@ -868,6 +868,8 @@ i40e_status i40e_asq_send_command(struct i40e_hw *hw,
cmd_completed = true;
if ((enum i40e_admin_queue_err)retval == I40E_AQ_RC_OK)
status = 0;
+ else if ((enum i40e_admin_queue_err)retval == I40E_AQ_RC_EBUSY)
+ status = I40E_ERR_NOT_READY;
else
status = I40E_ERR_ADMIN_QUEUE_ERROR;
hw->aq.asq_last_status = (enum i40e_admin_queue_err)retval;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq.c b/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
index c355120dfdfd..21a0dbf6ccf6 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
@@ -797,6 +797,8 @@ i40e_status i40evf_asq_send_command(struct i40e_hw *hw,
cmd_completed = true;
if ((enum i40e_admin_queue_err)retval == I40E_AQ_RC_OK)
status = 0;
+ else if ((enum i40e_admin_queue_err)retval == I40E_AQ_RC_EBUSY)
+ status = I40E_ERR_NOT_READY;
else
status = I40E_ERR_ADMIN_QUEUE_ERROR;
hw->aq.asq_last_status = (enum i40e_admin_queue_err)retval;
--
2.17.1
^ permalink raw reply related
* [net-next 06/12] i40e: convert VEB TC stats to use an i40e_stats array
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The VEB TC stats are currently implemented with separate parsing,
instead of using the i40e_stats array and associated helper functions.
This is likely because the stats rely on embedding the TC number into
the stat name.
Update i40e_add_stat_strings to take variadic arguments, and use these
to vsnprintf the i40e_stats string as a string containing format
specifiers.
Create a stats array for the VEB TC related stats,
i40e_gstrings_veb_tc_stats, and use this along with the helper functions
to remove the specialized boiler plate code.
Always call i40e_add_ethtool_stats for both this array and the general
VEB stats array. This ensures that we zero out any memory in case it was
not zero-allocated for us.
This ultimately results in less boiler plate code for the
i40e_get_stat_strings and i40e_get_ethtool_stats.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/i40e/i40e_ethtool.c | 83 ++++++++++---------
1 file changed, 43 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index c051afe98b49..52ccafe1d257 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -7,6 +7,11 @@
#include "i40e_diag.h"
struct i40e_stats {
+ /* The stat_string is expected to be a format string formatted using
+ * vsnprintf by i40e_add_stat_strings. Every member of a stats array
+ * should use the same format specifiers as they will be formatted
+ * using the same variadic arguments.
+ */
char stat_string[ETH_GSTRING_LEN];
int sizeof_stat;
int stat_offset;
@@ -56,6 +61,13 @@ static const struct i40e_stats i40e_gstrings_veb_stats[] = {
I40E_VEB_STAT("veb.rx_unknown_protocol", stats.rx_unknown_protocol),
};
+static const struct i40e_stats i40e_gstrings_veb_tc_stats[] = {
+ I40E_VEB_STAT("veb.tc_%u_tx_packets", tc_stats.tc_tx_packets),
+ I40E_VEB_STAT("veb.tc_%u_tx_bytes", tc_stats.tc_tx_bytes),
+ I40E_VEB_STAT("veb.tc_%u_rx_packets", tc_stats.tc_rx_packets),
+ I40E_VEB_STAT("veb.tc_%u_rx_bytes", tc_stats.tc_rx_bytes),
+};
+
static const struct i40e_stats i40e_gstrings_misc_stats[] = {
I40E_VSI_STAT("rx_unicast", eth_stats.rx_unicast),
I40E_VSI_STAT("tx_unicast", eth_stats.tx_unicast),
@@ -162,16 +174,14 @@ static const struct i40e_stats i40e_gstrings_stats[] = {
FIELD_SIZEOF(struct i40e_pf, stats.priority_xon_tx) + \
FIELD_SIZEOF(struct i40e_pf, stats.priority_xon_2_xoff)) \
/ sizeof(u64))
-#define I40E_VEB_TC_STATS_LEN ( \
- (FIELD_SIZEOF(struct i40e_veb, tc_stats.tc_rx_packets) + \
- FIELD_SIZEOF(struct i40e_veb, tc_stats.tc_rx_bytes) + \
- FIELD_SIZEOF(struct i40e_veb, tc_stats.tc_tx_packets) + \
- FIELD_SIZEOF(struct i40e_veb, tc_stats.tc_tx_bytes)) \
- / sizeof(u64))
-#define I40E_VEB_STATS_LEN ARRAY_SIZE(i40e_gstrings_veb_stats)
-#define I40E_VEB_STATS_TOTAL (I40E_VEB_STATS_LEN + I40E_VEB_TC_STATS_LEN)
+
+#define I40E_VEB_STATS_LEN (ARRAY_SIZE(i40e_gstrings_veb_stats) + \
+ (ARRAY_SIZE(i40e_gstrings_veb_tc_stats) * \
+ I40E_MAX_TRAFFIC_CLASS))
+
#define I40E_PF_STATS_LEN(n) (I40E_GLOBAL_STATS_LEN + \
I40E_PFC_STATS_LEN + \
+ I40E_VEB_STATS_LEN + \
I40E_VSI_STATS_LEN((n)))
enum i40e_ethtool_test_id {
@@ -1681,7 +1691,7 @@ static int i40e_get_stats_count(struct net_device *netdev)
struct i40e_pf *pf = vsi->back;
if (vsi == pf->vsi[pf->lan_vsi] && pf->hw.partition_id == 1)
- return I40E_PF_STATS_LEN(netdev) + I40E_VEB_STATS_TOTAL;
+ return I40E_PF_STATS_LEN(netdev);
else
return I40E_VSI_STATS_LEN(netdev);
}
@@ -1809,8 +1819,10 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
struct i40e_ring *tx_ring, *rx_ring;
struct i40e_vsi *vsi = np->vsi;
struct i40e_pf *pf = vsi->back;
+ struct i40e_veb *veb = pf->veb[pf->lan_veb];
unsigned int i;
unsigned int start;
+ bool veb_stats;
i40e_update_stats(vsi);
@@ -1855,21 +1867,19 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
if (vsi != pf->vsi[pf->lan_vsi] || pf->hw.partition_id != 1)
return;
- if ((pf->lan_veb != I40E_NO_VEB) &&
- (pf->flags & I40E_FLAG_VEB_STATS_ENABLED)) {
- struct i40e_veb *veb = pf->veb[pf->lan_veb];
+ veb_stats = ((pf->lan_veb != I40E_NO_VEB) &&
+ (pf->flags & I40E_FLAG_VEB_STATS_ENABLED));
- i40e_add_ethtool_stats(&data, veb, i40e_gstrings_veb_stats);
+ /* If veb stats aren't enabled, pass NULL instead of the veb so that
+ * we initialize stats to zero and update the data pointer
+ * intelligently
+ */
+ i40e_add_ethtool_stats(&data, veb_stats ? veb : NULL,
+ i40e_gstrings_veb_stats);
- for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
- *(data++) = veb->tc_stats.tc_tx_packets[i];
- *(data++) = veb->tc_stats.tc_tx_bytes[i];
- *(data++) = veb->tc_stats.tc_rx_packets[i];
- *(data++) = veb->tc_stats.tc_rx_bytes[i];
- }
- } else {
- data += I40E_VEB_STATS_TOTAL;
- }
+ for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++)
+ i40e_add_ethtool_stats(&data, veb_stats ? veb : NULL,
+ i40e_gstrings_veb_tc_stats);
i40e_add_ethtool_stats(&data, pf, i40e_gstrings_stats);
@@ -1891,16 +1901,21 @@ static void i40e_get_ethtool_stats(struct net_device *netdev,
* @stats: stat definitions array
* @size: size of the stats array
*
- * Copy the strings described by stats into the buffer pointed at by p.
+ * Format and copy the strings described by stats into the buffer pointed at
+ * by p.
**/
static void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
- const unsigned int size)
+ const unsigned int size, ...)
{
unsigned int i;
for (i = 0; i < size; i++) {
- snprintf(*p, ETH_GSTRING_LEN, "%s", stats[i].stat_string);
+ va_list args;
+
+ va_start(args, size);
+ vsnprintf(*p, ETH_GSTRING_LEN, stats[i].stat_string, args);
*p += ETH_GSTRING_LEN;
+ va_end(args);
}
}
@@ -1914,7 +1929,7 @@ static void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
* for it.
**/
#define i40e_add_stat_strings(p, stats, ...) \
- __i40e_add_stat_strings(p, stats, ARRAY_SIZE(stats))
+ __i40e_add_stat_strings(p, stats, ARRAY_SIZE(stats), ## __VA_ARGS__)
/**
* i40e_get_stat_strings - copy stat strings into supplied buffer
@@ -1953,20 +1968,8 @@ static void i40e_get_stat_strings(struct net_device *netdev, u8 *data)
i40e_add_stat_strings(&data, i40e_gstrings_veb_stats);
- for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
- snprintf(data, ETH_GSTRING_LEN,
- "veb.tc_%u_tx_packets", i);
- data += ETH_GSTRING_LEN;
- snprintf(data, ETH_GSTRING_LEN,
- "veb.tc_%u_tx_bytes", i);
- data += ETH_GSTRING_LEN;
- snprintf(data, ETH_GSTRING_LEN,
- "veb.tc_%u_rx_packets", i);
- data += ETH_GSTRING_LEN;
- snprintf(data, ETH_GSTRING_LEN,
- "veb.tc_%u_rx_bytes", i);
- data += ETH_GSTRING_LEN;
- }
+ for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++)
+ i40e_add_stat_strings(&data, i40e_gstrings_veb_tc_stats, i);
i40e_add_stat_strings(&data, i40e_gstrings_stats);
--
2.17.1
^ permalink raw reply related
* [net-next 08/12] i40e: remove unnecessary i variable causing -Wshadow warning
From: Jeff Kirsher @ 2018-08-07 19:27 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180807192757.21592-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Commit c61c8fe1d592 ("i40e: Implement an ethtool private flag to stop
LLDP in FW") added an extra for-loop which added a shadowing 'i'
variable as the index.
However, the local variable i already exists, and we already use it as
a loop index. Additionally, at this point, there is no further use of
the variable, so it's safe to simply overwrite the variable contents.
This fixes a -Wshadow warning which has started being enabled on some
distributions
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Patryk Malek <patryk.malek@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 9c380c0b0202..12d279a6eae8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -4642,7 +4642,6 @@ static int i40e_set_priv_flags(struct net_device *dev, u32 flags)
if (changed_flags & I40E_FLAG_DISABLE_FW_LLDP) {
if (pf->flags & I40E_FLAG_DISABLE_FW_LLDP) {
struct i40e_dcbx_config *dcbcfg;
- int i;
i40e_aq_stop_lldp(&pf->hw, true, NULL);
i40e_aq_set_dcb_parameters(&pf->hw, true, NULL);
--
2.17.1
^ 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