* Re: [PATCH v3 0/3] net: fddi: skfp: Use PCI generic definitions instead of private duplicates
From: David Miller @ 2019-06-26 20:03 UTC (permalink / raw)
To: skhan
Cc: gnomes, puranjay12, bjorn, stephen, netdev, linux-kernel,
linux-kernel-mentees, linux-pci
In-Reply-To: <5f04f52d-8911-4db9-4321-00334d357d54@linuxfoundation.org>
From: Shuah Khan <skhan@linuxfoundation.org>
Date: Fri, 21 Jun 2019 10:36:02 -0600
> Stephen Hemminger is suggesting removal as well. Makes sense to me.
...
> What would you recommend the next steps are? Would like driver
> removed?
If you hadn't proposed the cleanups nobody would have said to remove
this driver. Really if someone wants to go through the tree and
send removal patches for seemingly really unused drivers, that is
a separate piece of work unrelated to your cleanup.
While something still is in the tree we should clean it up from
stuff like this.
Therefore, I'll be applying v5 of your changes, thanks.
^ permalink raw reply
* Re: [PATCH net-next 10/10] net: stmmac: Try to get C45 PHY if everything else fails
From: Andrew Lunn @ 2019-06-26 20:01 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel, netdev, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <c7d1dbac1940853c22db8215ed60181b2abe3050.1561556556.git.joabreu@synopsys.com>
On Wed, Jun 26, 2019 at 03:47:44PM +0200, Jose Abreu wrote:
> On PCI based setups that are connected to C45 PHY we won't have DT
> bindings specifying what's the correct PHY type.
You can associate a DT node to a PCI device. The driver does not have
to do anything special, the PCI core code does all the work.
As an example look at imx6q-zii-rdu2.dts, node &pcie, which has an
intel i210 on the pcie bus, and we need a handle to it.
Andrew
^ permalink raw reply
* Re: XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support)
From: Jesper Dangaard Brouer @ 2019-06-26 20:00 UTC (permalink / raw)
To: Jonathan Lemon
Cc: Willem de Bruijn, Toke Høiland-Jørgensen,
Machulsky, Zorik, Jubran, Samih, davem, netdev, Woodhouse, David,
Matushevsky, Alexander, Bshara, Saeed, Wilson, Matt,
Liguori, Anthony, Bshara, Nafea, Tzalik, Guy, Belgazal, Netanel,
Saidi, Ali, Herrenschmidt, Benjamin, Kiyanovski, Arthur,
Daniel Borkmann, Ilias Apalodimas, Alexei Starovoitov,
Jakub Kicinski, xdp-newbies, brouer
In-Reply-To: <99AFC1EE-E27E-4D4D-B9B8-CA2215E68E1B@gmail.com>
On Wed, 26 Jun 2019 09:42:07 -0700 "Jonathan Lemon" <jonathan.lemon@gmail.com> wrote:
> If all packets are collected together (like the bulk queue does), and
> then passed to XDP, this could easily be made backwards compatible.
> If the XDP program isn't 'multi-frag' aware, then each packet is just
> passed in individually.
My proposal#1 is XDP only access first-buffer[1], as this simplifies things.
(AFAIK) What you are proposing is that all the buffers are passed to
the XDP prog (in form of a iovec). I need some more details about your
suggestion.
Specifically:
- What is the semantic when a 3 buffer packet is input and XDP prog
choose to return XDP_DROP for packet #2 ?
- Same situation of packet #2 wants a XDP_TX or redirect?
> Of course, passing in the equivalent of a iovec requires some form of
> loop support on the BPF side, doesn't it?
The data structure used for holding these packet buffers/segments also
needs to be discussed. I would either use an array of bio_vec[2] or
skb_frag_t (aka skb_frag_struct). The skb_frag_t would be most
obvious, as we already have to write this when creating an SKB, in
skb_shared_info area. (Structs listed below signature).
The problem is also that size of these structs (16 bytes) per
buffer/segment, and we likely need to support 17 segments, as this need
to be compatible with SKBs (size 272 bytes).
My idea here is that we simply use the same memory area, that we have to
store skb_shared_info into. As this allow us to get the SKB setup for
free, when doing XDP_PASS or when doing SKB alloc after XDP_REDIRECT.
[1] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org#proposal1-xdp-only-access-first-buffer
[2] https://lore.kernel.org/netdev/20190501041757.8647-1-willy@infradead.org/
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
$ pahole -C skb_frag_struct vmlinux
struct skb_frag_struct {
struct {
struct page * p; /* 0 8 */
} page; /* 0 8 */
__u32 page_offset; /* 8 4 */
__u32 size; /* 12 4 */
/* size: 16, cachelines: 1, members: 3 */
/* last cacheline: 16 bytes */
};
$ pahole -C bio_vec vmlinux
struct bio_vec {
struct page * bv_page; /* 0 8 */
unsigned int bv_len; /* 8 4 */
unsigned int bv_offset; /* 12 4 */
/* size: 16, cachelines: 1, members: 3 */
/* last cacheline: 16 bytes */
};
$ pahole -C skb_shared_info vmlinux
struct skb_shared_info {
__u8 __unused; /* 0 1 */
__u8 meta_len; /* 1 1 */
__u8 nr_frags; /* 2 1 */
__u8 tx_flags; /* 3 1 */
short unsigned int gso_size; /* 4 2 */
short unsigned int gso_segs; /* 6 2 */
struct sk_buff * frag_list; /* 8 8 */
struct skb_shared_hwtstamps hwtstamps; /* 16 8 */
unsigned int gso_type; /* 24 4 */
u32 tskey; /* 28 4 */
atomic_t dataref; /* 32 0 */
/* XXX 8 bytes hole, try to pack */
void * destructor_arg; /* 40 8 */
skb_frag_t frags[17]; /* 48 272 */
/* size: 320, cachelines: 5, members: 13 */
/* sum members: 312, holes: 1, sum holes: 8 */
};
^ permalink raw reply
* Re: [net-next 2/4] gve: Add transmit and receive support
From: David Miller @ 2019-06-26 19:49 UTC (permalink / raw)
To: csully; +Cc: netdev, sagis, jonolson, willemb, lrizzo
In-Reply-To: <20190626185251.205687-3-csully@google.com>
From: Catherine Sullivan <csully@google.com>
Date: Wed, 26 Jun 2019 11:52:49 -0700
> +#ifdef __LITTLE_ENDIAN
> +#define GVE_SEQNO(x) ((((__force u16)x) >> 8) & 0x7)
> +#else
> +#define GVE_SEQNO(x) ((__force u16)(x) & 0x7)
> +#endif
This can be simply "le16_to_cpu(x) & 0x7" or similar. No need to
messy ifdefs.
^ permalink raw reply
* Re: [net-next 4/4] gve: Add ethtool support
From: Andrew Lunn @ 2019-06-26 19:48 UTC (permalink / raw)
To: Catherine Sullivan
Cc: netdev, Sagi Shahar, Jon Olson, Willem de Bruijn, Luigi Rizzo
In-Reply-To: <20190626185251.205687-5-csully@google.com>
> +static int gve_get_sset_count(struct net_device *netdev, int sset)
> +{
> + struct gve_priv *priv = netdev_priv(netdev);
> +
> + if (!netif_carrier_ok(netdev))
> + return 0;
That is pretty unusual. What goes wrong if there is no carrier and
statistics are returned?
> +static void
> +gve_get_ethtool_stats(struct net_device *netdev,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + struct gve_priv *priv = netdev_priv(netdev);
> + u64 rx_pkts, rx_bytes, tx_pkts, tx_bytes;
> + int ring;
> + int i;
> +
> + ASSERT_RTNL();
> +
> + if (!netif_carrier_ok(netdev))
> + return;
> +
> + for (rx_pkts = 0, rx_bytes = 0, ring = 0;
> + ring < priv->rx_cfg.num_queues; ring++) {
> + rx_pkts += priv->rx[ring].rpackets;
> + rx_bytes += priv->rx[ring].rbytes;
> + }
> + for (tx_pkts = 0, tx_bytes = 0, ring = 0;
> + ring < priv->tx_cfg.num_queues; ring++) {
> + tx_pkts += priv->tx[ring].pkt_done;
> + tx_bytes += priv->tx[ring].bytes_done;
> + }
> + memset(data, 0, GVE_MAIN_STATS_LEN * sizeof(*data));
Maybe you should do this memset when the carrier is off?
Andrew
^ permalink raw reply
* Re: [PATCH net-next v6 1/8] igb: clear out skb->tstamp after reading the txtime
From: Jeff Kirsher @ 2019-06-26 19:44 UTC (permalink / raw)
To: Vedang Patel, netdev
Cc: davem, jhs, xiyou.wangcong, jiri, intel-wired-lan, vinicius.gomes,
l, jakub.kicinski, m-karicheri2, sergei.shtylyov, eric.dumazet,
aaron.f.brown
In-Reply-To: <1561500439-30276-2-git-send-email-vedang.patel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]
On Tue, 2019-06-25 at 15:07 -0700, Vedang Patel wrote:
> If a packet which is utilizing the launchtime feature (via SO_TXTIME
> socket
> option) also requests the hardware transmit timestamp, the hardware
> timestamp is not delivered to the userspace. This is because the
> value in
> skb->tstamp is mistaken as the software timestamp.
>
> Applications, like ptp4l, request a hardware timestamp by setting the
> SOF_TIMESTAMPING_TX_HARDWARE socket option. Whenever a new timestamp
> is
> detected by the driver (this work is done in igb_ptp_tx_work() which
> calls
> igb_ptp_tx_hwtstamps() in igb_ptp.c[1]), it will queue the timestamp
> in the
> ERR_QUEUE for the userspace to read. When the userspace is ready, it
> will
> issue a recvmsg() call to collect this timestamp. The problem is in
> this
> recvmsg() call. If the skb->tstamp is not cleared out, it will be
> interpreted as a software timestamp and the hardware tx timestamp
> will not
> be successfully sent to the userspace. Look at skb_is_swtx_tstamp()
> and the
> callee function __sock_recv_timestamp() in net/socket.c for more
> details.
>
> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> 1 file changed, 1 insertion(+)
Since this fix is really not needed for the rest of the patch series,
if you have to do another version of the series, can you drop this
patch from any future version? I don't want to keep spinning my
validation team on a updated version of this patch, that is not really
being updated.
I plan to take this version of the patch and will hold onto it for my
next 1GbE updates to Dave.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [net-next 2/4] gve: Add transmit and receive support
From: Andrew Lunn @ 2019-06-26 19:42 UTC (permalink / raw)
To: Catherine Sullivan
Cc: netdev, Sagi Shahar, Jon Olson, Willem de Bruijn, Luigi Rizzo
In-Reply-To: <20190626185251.205687-3-csully@google.com>
> +static int gve_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + dev->mtu = new_mtu;
> + return 0;
> +}
The default implementation does this.
Also, i think your mtu has a limit of PAGE size. So you should set
the dev->max_mtu so the core will enforce this.
Andrew
^ permalink raw reply
* Re: [PATCH net v2] ipv4: reset rt_iif for recirculated mcast/bcast out pkts
From: David Miller @ 2019-06-26 19:40 UTC (permalink / raw)
To: ssuryaextr; +Cc: netdev, dsahern
In-Reply-To: <20190626062116.4319-1-ssuryaextr@gmail.com>
From: Stephen Suryaputra <ssuryaextr@gmail.com>
Date: Wed, 26 Jun 2019 02:21:16 -0400
> Multicast or broadcast egress packets have rt_iif set to the oif. These
> packets might be recirculated back as input and lookup to the raw
> sockets may fail because they are bound to the incoming interface
> (skb_iif). If rt_iif is not zero, during the lookup, inet_iif() function
> returns rt_iif instead of skb_iif. Hence, the lookup fails.
>
> v2: Make it non vrf specific (David Ahern). Reword the changelog to
> reflect it.
> Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: eBPF verifier slowness, more than 2 cpu seconds for about 600 instructions
From: Alexei Starovoitov @ 2019-06-26 19:38 UTC (permalink / raw)
To: Andreas Steinmetz, Daniel Borkmann, Andrii Nakryiko, Edward Cree
Cc: bpf, Network Development
In-Reply-To: <20190618214028.y2qzbtonozr5cc7a@ast-mbp.dhcp.thefacebook.com>
On Tue, Jun 18, 2019 at 2:40 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Mon, Jun 17, 2019 at 11:26:28AM -0700, Alexei Starovoitov wrote:
> > On Sun, Jun 16, 2019 at 11:59 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Thu, Jun 6, 2019 at 6:31 PM Andreas Steinmetz <ast@domdv.de> wrote:
> > > >
> > > > Below is the source in question. It may look a bit strange but I
> > > > had to extract it from the project and preset parameters to fixed
> > > > values.
> > > > It takes from 2.8 to 4.5 seconds to load, depending on the processor.
> > > > Just compile and run the code below.
> > >
> > > Thanks for the report.
> > > It's interesting one indeed.
> > > 600+ instructions consume
> > > processed 280464 insns (limit 1000000) max_states_per_insn 15
> > > total_states 87341 peak_states 580 mark_read 45
> > >
> > > The verifier finds a lot of different ways to go through branches
> > > in the program and majority of the states are not equivalent and
> > > do not help pruning, so it's doing full brute force walk of all possible
> > > combinations.
> > > We need to figure out whether there is a way to make it smarter.
> >
> > btw my pending backtracking logic helps it quite a bit:
> > processed 164110 insns (limit 1000000) max_states_per_insn 11
> > total_states 13398 peak_states 349 mark_read 10
> >
> > and it's 2x faster to verify, but 164k insns processed shows that
> > there is still room for improvement.
>
> Hi Andreas,
>
> Could you please create selftests/bpf/verifier/.c out of it?
> Currently we don't have a single test that exercises the verifier this way.
> Could you also annotate instructions with comments like you did
> at the top of your file?
Andreas, ping.
> The program logic is interesting.
> If my understanding of assembler is correct it has unrolled
> parsing of ipv6 extension headers. Then unrolled parsing of tcp options.
> The way the program is using packet pointers forces the verifier to try
> all possible combinations of extension headers and tcp options.
>
> The precise backtracking logic helps to reduce amount of walking.
> Also I think it's safe to reduce precision of variable part
> of packet pointers. The following patch on top of bounded loop
> series help to reduce it further.
>
> Original:
> processed 280464 insns (limit 1000000) max_states_per_insn 15
> total_states 87341 peak_states 580 mark_read 45
>
> Backtracking:
> processed 164110 insns (limit 1000000) max_states_per_insn 11
> total_states 13398 peak_states 349 mark_read 10
>
> Backtracking + pkt_ptr var precision:
> processed 96739 insns (limit 1000000) max_states_per_insn 11
> total_states 7891 peak_states 329 mark_read 10
>
> The patch helps w/o backtracking as well:
> processed 165254 insns (limit 1000000) max_states_per_insn 15
> total_states 51434 peak_states 572 mark_read 45
>
> Backtracking and bounded loop heuristics reduce total memory
> consumption quite a bit. Which was nice to see.
>
> Anyway would be great if you could create a test out of it.
> Would be even more awesome if you convert it to C code
> and try to use bounded loops to parse extension headers
> and tcp options. That would be a true test for both loops
> and 'reduce precision' features.
>
> Thanks!
>
> From 4681224057af73335de0fdd629a2149bad91d59d Mon Sep 17 00:00:00 2001
> From: Alexei Starovoitov <ast@kernel.org>
> Date: Tue, 18 Jun 2019 13:40:29 -0700
> Subject: [PATCH bpf-next] bpf: relax tracking of variable offset in packet pointers
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> kernel/bpf/verifier.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d2c8a6677ac4..e37c69ad57b3 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3730,6 +3730,27 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
> dst_reg->id = ++env->id_gen;
> /* something was added to pkt_ptr, set range to zero */
> dst_reg->raw = 0;
> + if (bpf_prog_is_dev_bound(env->prog->aux))
> + /* nfp offload needs accurate max_pkt_offset */
> + break;
> + if (env->strict_alignment)
> + break;
> + /* scalar added to pkt pointer is within BPF_MAX_VAR_OFF bounds.
> + * 64-bit pkt_data pointer can be safely compared with pkt_data_end
> + * even on 32-bit architectures.
> + * In case this scalar was positive the verifier
> + * doesn't need to track it precisely.
> + */
> + if (dst_reg->smin_value >= 0)
> + /* clear variable part of pkt pointer */
> + __mark_reg_known_zero(dst_reg);
> + /* no need to clear dst_reg->off.
> + * It's a known part of the pointer.
> + * When this pkt_ptr compared with pkt_end
> + * the 'range' will be initialized from 'off' and
> + * *(u8*)(dst_reg - off) is still more than packet start,
> + * since unknown value was positive.
> + */
> }
> break;
> case BPF_SUB:
> --
> 2.20.0
>
^ permalink raw reply
* Re: [net-next 1/4] gve: Add basic driver framework for Compute Engine Virtual NIC
From: Andrew Lunn @ 2019-06-26 19:35 UTC (permalink / raw)
To: Catherine Sullivan
Cc: netdev, Sagi Shahar, Jon Olson, Willem de Bruijn, Luigi Rizzo
In-Reply-To: <20190626185251.205687-2-csully@google.com>
On Wed, Jun 26, 2019 at 11:52:48AM -0700, Catherine Sullivan wrote:
> Add a driver framework for the Compute Engine Virtual NIC that will be
> available in the future.
>
> +static int __init gvnic_init_module(void)
> +{
> + return pci_register_driver(&gvnic_driver);
> +}
> +
> +static void __exit gvnic_exit_module(void)
> +{
> + pci_unregister_driver(&gvnic_driver);
> +}
> +
> +module_init(gvnic_init_module);
> +module_exit(gvnic_exit_module);
module_pci_driver()?
Andrew
^ permalink raw reply
* [net-next 02/10] ixgbevf: fix possible divide by zero in ixgbevf_update_itr
From: Jeff Kirsher @ 2019-06-26 19:30 UTC (permalink / raw)
To: davem; +Cc: Young Xiao, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Young Xiao <92siuyang@gmail.com>
The next call to ixgbevf_update_itr will continue to dynamically
update ITR.
Copy from commit bdbeefe8ea8c ("ixgbe: fix possible divide by zero in
ixgbe_update_itr")
Signed-off-by: Young Xiao <92siuyang@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index d189ed247665..d2b41f9f87f8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1423,6 +1423,9 @@ static void ixgbevf_update_itr(struct ixgbevf_q_vector *q_vector,
*/
/* what was last interrupt timeslice? */
timepassed_us = q_vector->itr >> 2;
+ if (timepassed_us == 0)
+ return;
+
bytes_perint = bytes / timepassed_us; /* bytes/usec */
switch (itr_setting) {
--
2.21.0
^ permalink raw reply related
* [net-next 00/10][pull request] Intel Wired LAN Driver Updates 2019-06-26
From: Jeff Kirsher @ 2019-06-26 19:30 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to ixgbe and i40e only.
Mauro S. M. Rodrigues update the ixgbe driver to handle transceivers who
comply with SFF-8472 but do not implement the Digital Diagnostic
Monitoring (DOM) interface. Update the driver to check the necessary
bits to see if DOM is implemented before trying to read the additional
256 bytes in the EEPROM for DOM data.
Young Xiao fixes a potential divide by zero issue in ixgbe driver.
Aleksandr fixes i40e to recognize 2.5 and 5.0 GbE link speeds so that it
is not reported as "Unknown bps". Fixes the driver to read the firmware
LLDP agent status during DCB initialization, and to properly log the
LLDP agent status to help with debugging when DCB fails to initialize.
Martyna fixes i40e for the missing supported and advertised link modes
information in ethtool.
Jake fixes a function header comment that was incorrect for a PTP
function in i40e.
Maciej fixes an issue for i40e when a XDP program is loaded the
descriptor count gets reset to the default value, resolve the issue by
making the current descriptor count persistent across resets.
Alice corrects a copyright date which she found to be incorrect.
Piotr adds a log entry when the traffic class 0 is added or deleted, which
was not being logged previously.
Gustavo A. R. Silva updates i40e to use struct_size() where possible.
The following are changes since commit 3b525691529b01cbea03ce07e5df487da5e44a31:
ipv6: fix suspicious RCU usage in rt6_dump_route()
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Aleksandr Loktionov (2):
i40e: fix 'Unknown bps' in dmesg for 2.5Gb/5Gb speeds
i40e: missing priorities for any QoS traffic
Alice Michael (1):
i40e: update copyright string
Gustavo A. R. Silva (1):
i40e/i40e_virtchnl_pf: Use struct_size() in kzalloc()
Jacob Keller (1):
i40e: fix incorrect function documentation comment
Maciej Fijalkowski (1):
i40e: Fix descriptor count manipulation
Martyna Szapar (1):
i40e: Fix for missing "link modes" info in ethtool
Mauro S. M. Rodrigues (1):
ixgbe: Check DDM existence in transceiver before access
Piotr Kwapulinski (1):
i40e: Add log entry while creating or deleting TC0
Young Xiao (1):
ixgbevf: fix possible divide by zero in ixgbevf_update_itr
drivers/net/ethernet/intel/i40e/i40e.h | 3 +-
drivers/net/ethernet/intel/i40e/i40e_common.c | 3 +-
.../net/ethernet/intel/i40e/i40e_debugfs.c | 5 +-
.../net/ethernet/intel/i40e/i40e_ethtool.c | 4 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 99 ++++++++++++++++---
.../net/ethernet/intel/i40e/i40e_prototype.h | 4 +
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 3 +-
.../ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 ++-
.../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h | 1 +
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +
include/linux/avf/virtchnl.h | 4 +
12 files changed, 115 insertions(+), 32 deletions(-)
--
2.21.0
^ permalink raw reply
* [net-next 08/10] i40e: Fix descriptor count manipulation
From: Jeff Kirsher @ 2019-06-26 19:31 UTC (permalink / raw)
To: davem
Cc: Maciej Fijalkowski, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Changing descriptor count via 'ethtool -G' is not persistent across resets.
When PF reset occurs, we roll back to the default value of vsi->num_desc,
which is used then in i40e_alloc_rings to set descriptor count. XDP does a
PF reset so when user has changed the descriptor count and load XDP
program, the default count will be back there.
To fix this:
* introduce new VSI members - num_tx_desc and num_rx_desc in favour of
num_desc
* set them in i40e_set_ringparam to user's values
* set them to default values in i40e_set_num_rings_in_vsi only when they
don't have previous values
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@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.h | 3 +-
.../net/ethernet/intel/i40e/i40e_debugfs.c | 5 +--
.../net/ethernet/intel/i40e/i40e_ethtool.c | 4 +++
drivers/net/ethernet/intel/i40e/i40e_main.c | 36 +++++++++++++------
4 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 8dc98d1d2e86..24e6ce6517a7 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -775,7 +775,8 @@ struct i40e_vsi {
u16 alloc_queue_pairs; /* Allocated Tx/Rx queues */
u16 req_queue_pairs; /* User requested queue pairs */
u16 num_queue_pairs; /* Used tx and rx pairs */
- u16 num_desc;
+ u16 num_tx_desc;
+ u16 num_rx_desc;
enum i40e_vsi_type type; /* VSI type, e.g., LAN, FCoE, etc */
s16 vf_id; /* Virtual function ID for SRIOV VSIs */
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index dc5b40013e61..55d20acfcf70 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -333,8 +333,9 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
" seid = %d, id = %d, uplink_seid = %d\n",
vsi->seid, vsi->id, vsi->uplink_seid);
dev_info(&pf->pdev->dev,
- " base_queue = %d, num_queue_pairs = %d, num_desc = %d\n",
- vsi->base_queue, vsi->num_queue_pairs, vsi->num_desc);
+ " base_queue = %d, num_queue_pairs = %d, num_tx_desc = %d, num_rx_desc = %d\n",
+ vsi->base_queue, vsi->num_queue_pairs, vsi->num_tx_desc,
+ vsi->num_rx_desc);
dev_info(&pf->pdev->dev, " type = %i\n", vsi->type);
if (vsi->type == I40E_VSI_SRIOV)
dev_info(&pf->pdev->dev, " VF ID = %i\n", vsi->vf_id);
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index a6c5e10421dd..527eb52c5401 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1982,6 +1982,8 @@ static int i40e_set_ringparam(struct net_device *netdev,
if (i40e_enabled_xdp_vsi(vsi))
vsi->xdp_rings[i]->count = new_tx_count;
}
+ vsi->num_tx_desc = new_tx_count;
+ vsi->num_rx_desc = new_rx_count;
goto done;
}
@@ -2118,6 +2120,8 @@ static int i40e_set_ringparam(struct net_device *netdev,
rx_rings = NULL;
}
+ vsi->num_tx_desc = new_tx_count;
+ vsi->num_rx_desc = new_rx_count;
i40e_up(vsi);
free_tx:
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 6a10f9f9479c..ff1525e0dc3d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -10078,8 +10078,12 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
switch (vsi->type) {
case I40E_VSI_MAIN:
vsi->alloc_queue_pairs = pf->num_lan_qps;
- vsi->num_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
- I40E_REQ_DESCRIPTOR_MULTIPLE);
+ if (!vsi->num_tx_desc)
+ vsi->num_tx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
+ if (!vsi->num_rx_desc)
+ vsi->num_rx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
if (pf->flags & I40E_FLAG_MSIX_ENABLED)
vsi->num_q_vectors = pf->num_lan_msix;
else
@@ -10089,22 +10093,32 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
case I40E_VSI_FDIR:
vsi->alloc_queue_pairs = 1;
- vsi->num_desc = ALIGN(I40E_FDIR_RING_COUNT,
- I40E_REQ_DESCRIPTOR_MULTIPLE);
+ vsi->num_tx_desc = ALIGN(I40E_FDIR_RING_COUNT,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
+ vsi->num_rx_desc = ALIGN(I40E_FDIR_RING_COUNT,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
vsi->num_q_vectors = pf->num_fdsb_msix;
break;
case I40E_VSI_VMDQ2:
vsi->alloc_queue_pairs = pf->num_vmdq_qps;
- vsi->num_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
- I40E_REQ_DESCRIPTOR_MULTIPLE);
+ if (!vsi->num_tx_desc)
+ vsi->num_tx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
+ if (!vsi->num_rx_desc)
+ vsi->num_rx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
vsi->num_q_vectors = pf->num_vmdq_msix;
break;
case I40E_VSI_SRIOV:
vsi->alloc_queue_pairs = pf->num_vf_qps;
- vsi->num_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
- I40E_REQ_DESCRIPTOR_MULTIPLE);
+ if (!vsi->num_tx_desc)
+ vsi->num_tx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
+ if (!vsi->num_rx_desc)
+ vsi->num_rx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
+ I40E_REQ_DESCRIPTOR_MULTIPLE);
break;
default:
@@ -10380,7 +10394,7 @@ static int i40e_alloc_rings(struct i40e_vsi *vsi)
ring->vsi = vsi;
ring->netdev = vsi->netdev;
ring->dev = &pf->pdev->dev;
- ring->count = vsi->num_desc;
+ ring->count = vsi->num_tx_desc;
ring->size = 0;
ring->dcb_tc = 0;
if (vsi->back->hw_features & I40E_HW_WB_ON_ITR_CAPABLE)
@@ -10397,7 +10411,7 @@ static int i40e_alloc_rings(struct i40e_vsi *vsi)
ring->vsi = vsi;
ring->netdev = NULL;
ring->dev = &pf->pdev->dev;
- ring->count = vsi->num_desc;
+ ring->count = vsi->num_tx_desc;
ring->size = 0;
ring->dcb_tc = 0;
if (vsi->back->hw_features & I40E_HW_WB_ON_ITR_CAPABLE)
@@ -10413,7 +10427,7 @@ static int i40e_alloc_rings(struct i40e_vsi *vsi)
ring->vsi = vsi;
ring->netdev = vsi->netdev;
ring->dev = &pf->pdev->dev;
- ring->count = vsi->num_desc;
+ ring->count = vsi->num_rx_desc;
ring->size = 0;
ring->dcb_tc = 0;
ring->itr_setting = pf->rx_itr_default;
--
2.21.0
^ permalink raw reply related
* [net-next 06/10] i40e: Add log entry while creating or deleting TC0
From: Jeff Kirsher @ 2019-06-26 19:30 UTC (permalink / raw)
To: davem
Cc: Piotr Kwapulinski, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Piotr Kwapulinski <piotr.kwapulinski@intel.com>
Generate log entry when TC0 is created or deleted.
Log entry is generated during main VSI setup.
Before there was no log info about adding or deleting TC0.
Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@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_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 7c43ec533385..eee4dbf40fec 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -6960,6 +6960,10 @@ static int i40e_setup_tc(struct net_device *netdev, void *type_data)
vsi->seid);
need_reset = true;
goto exit;
+ } else {
+ dev_info(&vsi->back->pdev->dev,
+ "Setup channel (id:%u) utilizing num_queues %d\n",
+ vsi->seid, vsi->tc_config.tc_info[0].qcount);
}
if (pf->flags & I40E_FLAG_TC_MQPRIO) {
--
2.21.0
^ permalink raw reply related
* [net-next 04/10] i40e: Fix for missing "link modes" info in ethtool
From: Jeff Kirsher @ 2019-06-26 19:30 UTC (permalink / raw)
To: davem
Cc: Martyna Szapar, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Martyna Szapar <martyna.szapar@intel.com>
Fix for missing "Supported link modes" and "Advertised link modes"
info in ethtool after changed speed on X722 devices with BASE-T PHY
with FW API version >= 1.7.
The same FW API version on X710 and X722 does not mean the same
feature set so the change was needed as mac type of the device
should also be checked instead of FW API version only.
Signed-off-by: Martyna Szapar <martyna.szapar@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_common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 641b500ad919..906cf68d3453 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -1861,8 +1861,7 @@ i40e_status i40e_aq_get_link_info(struct i40e_hw *hw,
hw->aq.fw_min_ver < 40)) && hw_link_info->phy_type == 0xE)
hw_link_info->phy_type = I40E_PHY_TYPE_10GBASE_SFPP_CU;
- if (hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
- hw->aq.api_min_ver >= 7) {
+ if (hw->flags & I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE) {
__le32 tmp;
memcpy(&tmp, resp->link_type, sizeof(tmp));
--
2.21.0
^ permalink raw reply related
* [net-next 09/10] i40e: update copyright string
From: Jeff Kirsher @ 2019-06-26 19:31 UTC (permalink / raw)
To: davem; +Cc: Alice Michael, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Alice Michael <alice.michael@intel.com>
It was found that the string that prints our copyright was
not up to date. Updating to reflect our copyright.
Signed-off-by: Alice Michael <alice.michael@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_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ff1525e0dc3d..8b0c29b7809b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -32,7 +32,7 @@ static const char i40e_driver_string[] =
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) DRV_KERN
const char i40e_driver_version_str[] = DRV_VERSION;
-static const char i40e_copyright[] = "Copyright (c) 2013 - 2014 Intel Corporation.";
+static const char i40e_copyright[] = "Copyright (c) 2013 - 2019 Intel Corporation.";
/* a bit of forward declarations */
static void i40e_vsi_reinit_locked(struct i40e_vsi *vsi);
--
2.21.0
^ permalink raw reply related
* [net-next 05/10] i40e: fix incorrect function documentation comment
From: Jeff Kirsher @ 2019-06-26 19:30 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
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_ptp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
index 439c35f0c581..11394a52e21c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
@@ -140,8 +140,7 @@ static int i40e_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
* @ptp: The PTP clock structure
* @delta: Offset in nanoseconds to adjust the PHC time by
*
- * Adjust the frequency of the PHC by the indicated parts per billion from the
- * base frequency.
+ * Adjust the current clock time by a delta specified in nanoseconds.
**/
static int i40e_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
{
--
2.21.0
^ permalink raw reply related
* [net-next 10/10] i40e/i40e_virtchnl_pf: Use struct_size() in kzalloc()
From: Jeff Kirsher @ 2019-06-26 19:31 UTC (permalink / raw)
To: davem
Cc: Gustavo A. R. Silva, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct virtchnl_iwarp_qvlist_info {
...
struct virtchnl_iwarp_qv_info qv_info[1];
};
size = sizeof(struct virtchnl_iwarp_qvlist_info) + (sizeof(struct virtchnl_iwarp_qv_info) * count;
instance = kzalloc(size, GFP_KERNEL);
and
struct virtchnl_vf_resource {
...
struct virtchnl_vsi_resource vsi_res[1];
};
size = sizeof(struct virtchnl_vf_resource) + sizeof(struct virtchnl_vsi_resource) * count;
instance = kzalloc(size, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, qv_info, count), GFP_KERNEL);
and
instance = kzalloc(struct_size(instance, vsi_res, count), GFP_KERNEL);
Notice that, in the first case above, variable size is not necessary, hence it
is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index ac3a130ee7d4..02b09a8ad54c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -440,7 +440,7 @@ static int i40e_config_iwarp_qvlist(struct i40e_vf *vf,
struct virtchnl_iwarp_qv_info *qv_info;
u32 v_idx, i, reg_idx, reg;
u32 next_q_idx, next_q_type;
- u32 msix_vf, size;
+ u32 msix_vf;
int ret = 0;
msix_vf = pf->hw.func_caps.num_msix_vectors_vf;
@@ -454,11 +454,10 @@ static int i40e_config_iwarp_qvlist(struct i40e_vf *vf,
goto err_out;
}
- size = sizeof(struct virtchnl_iwarp_qvlist_info) +
- (sizeof(struct virtchnl_iwarp_qv_info) *
- (qvlist_info->num_vectors - 1));
kfree(vf->qvlist_info);
- vf->qvlist_info = kzalloc(size, GFP_KERNEL);
+ vf->qvlist_info = kzalloc(struct_size(vf->qvlist_info, qv_info,
+ qvlist_info->num_vectors - 1),
+ GFP_KERNEL);
if (!vf->qvlist_info) {
ret = -ENOMEM;
goto err_out;
@@ -1846,7 +1845,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg)
i40e_status aq_ret = 0;
struct i40e_vsi *vsi;
int num_vsis = 1;
- int len = 0;
+ size_t len = 0;
int ret;
if (!test_bit(I40E_VF_STATE_INIT, &vf->vf_states)) {
@@ -1854,9 +1853,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg)
goto err;
}
- len = (sizeof(struct virtchnl_vf_resource) +
- sizeof(struct virtchnl_vsi_resource) * num_vsis);
-
+ len = struct_size(vfres, vsi_res, num_vsis);
vfres = kzalloc(len, GFP_KERNEL);
if (!vfres) {
aq_ret = I40E_ERR_NO_MEMORY;
--
2.21.0
^ permalink raw reply related
* [net-next 07/10] i40e: missing priorities for any QoS traffic
From: Jeff Kirsher @ 2019-06-26 19:31 UTC (permalink / raw)
To: davem
Cc: Aleksandr Loktionov, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
This patch fixes reading f/w LLDP agent status at DCB init time.
It's done by removing direct NVM reading in i40e_update_dcb_config()
and checking whether f/w LLDP agent is disabled via
I40E_FLAG_DISABLE_FW_LLDP flag in i40e_init_pf_dcb(). The function
i40e_update_dcb_config() in i40e_main.c is a temporary solution which
will be later renamed to i40e_init_dcb() in the i40e_dcb module. Also
logging was extended to make visible if f/w LLDP agent is running or not
and always log a message when DCB was not initialized. Without this
patch for new f/w versions f/w LLDP agent status was always read
from NVM as disabled and DCB initialization failed without
clear reason in logs.
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@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_main.c | 57 +++++++++++++++++++--
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index eee4dbf40fec..6a10f9f9479c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -6409,6 +6409,50 @@ static int i40e_resume_port_tx(struct i40e_pf *pf)
return ret;
}
+/**
+ * i40e_update_dcb_config
+ * @hw: pointer to the HW struct
+ * @enable_mib_change: enable MIB change event
+ *
+ * Update DCB configuration from the firmware
+ **/
+static enum i40e_status_code
+i40e_update_dcb_config(struct i40e_hw *hw, bool enable_mib_change)
+{
+ struct i40e_lldp_variables lldp_cfg;
+ i40e_status ret;
+
+ if (!hw->func_caps.dcb)
+ return I40E_NOT_SUPPORTED;
+
+ /* Read LLDP NVM area */
+ ret = i40e_read_lldp_cfg(hw, &lldp_cfg);
+ if (ret)
+ return I40E_ERR_NOT_READY;
+
+ /* Get DCBX status */
+ ret = i40e_get_dcbx_status(hw, &hw->dcbx_status);
+ if (ret)
+ return ret;
+
+ /* Check the DCBX Status */
+ if (hw->dcbx_status == I40E_DCBX_STATUS_DONE ||
+ hw->dcbx_status == I40E_DCBX_STATUS_IN_PROGRESS) {
+ /* Get current DCBX configuration */
+ ret = i40e_get_dcb_config(hw);
+ if (ret)
+ return ret;
+ } else if (hw->dcbx_status == I40E_DCBX_STATUS_DISABLED) {
+ return I40E_ERR_NOT_READY;
+ }
+
+ /* Configure the LLDP MIB change event */
+ if (enable_mib_change)
+ ret = i40e_aq_cfg_lldp_mib_change_event(hw, true, NULL);
+
+ return ret;
+}
+
/**
* i40e_init_pf_dcb - Initialize DCB configuration
* @pf: PF being configured
@@ -6425,11 +6469,13 @@ static int i40e_init_pf_dcb(struct i40e_pf *pf)
* Also do not enable DCBx if FW LLDP agent is disabled
*/
if ((pf->hw_features & I40E_HW_NO_DCB_SUPPORT) ||
- (pf->flags & I40E_FLAG_DISABLE_FW_LLDP))
+ (pf->flags & I40E_FLAG_DISABLE_FW_LLDP)) {
+ dev_info(&pf->pdev->dev, "DCB is not supported or FW LLDP is disabled\n");
+ err = I40E_NOT_SUPPORTED;
goto out;
+ }
- /* Get the initial DCB configuration */
- err = i40e_init_dcb(hw, true);
+ err = i40e_update_dcb_config(hw, true);
if (!err) {
/* Device/Function is not DCBX capable */
if ((!hw->func_caps.dcb) ||
@@ -14401,6 +14447,11 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, pf);
pci_save_state(pdev);
+ dev_info(&pdev->dev,
+ (pf->flags & I40E_FLAG_DISABLE_FW_LLDP) ?
+ "FW LLDP is disabled\n" :
+ "FW LLDP is enabled\n");
+
/* Enable FW to write default DCB config on link-up */
i40e_aq_set_dcb_parameters(hw, true, NULL);
--
2.21.0
^ permalink raw reply related
* [net-next 03/10] i40e: fix 'Unknown bps' in dmesg for 2.5Gb/5Gb speeds
From: Jeff Kirsher @ 2019-06-26 19:30 UTC (permalink / raw)
To: davem
Cc: Aleksandr Loktionov, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
This patch fixes 'NIC Link is Up, Unknown bps' message in dmesg
for 2.5Gb/5Gb speeds. This problem is fixed by adding constants
for VIRTCHNL_LINK_SPEED_2_5GB and VIRTCHNL_LINK_SPEED_5GB cases
in the i40e_virtchnl_link_speed() function.
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@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_prototype.h | 4 ++++
include/linux/avf/virtchnl.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_prototype.h b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
index 882627073dce..eac88bcc6c06 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_prototype.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
@@ -350,6 +350,10 @@ i40e_virtchnl_link_speed(enum i40e_aq_link_speed link_speed)
return VIRTCHNL_LINK_SPEED_100MB;
case I40E_LINK_SPEED_1GB:
return VIRTCHNL_LINK_SPEED_1GB;
+ case I40E_LINK_SPEED_2_5GB:
+ return VIRTCHNL_LINK_SPEED_2_5GB;
+ case I40E_LINK_SPEED_5GB:
+ return VIRTCHNL_LINK_SPEED_5GB;
case I40E_LINK_SPEED_10GB:
return VIRTCHNL_LINK_SPEED_10GB;
case I40E_LINK_SPEED_40GB:
diff --git a/include/linux/avf/virtchnl.h b/include/linux/avf/virtchnl.h
index 191621ff7594..ca956b672ac0 100644
--- a/include/linux/avf/virtchnl.h
+++ b/include/linux/avf/virtchnl.h
@@ -61,12 +61,14 @@ enum virtchnl_status_code {
#define VIRTCHNL_ERR_PARAM VIRTCHNL_STATUS_ERR_PARAM
#define VIRTCHNL_STATUS_NOT_SUPPORTED VIRTCHNL_STATUS_ERR_NOT_SUPPORTED
+#define VIRTCHNL_LINK_SPEED_2_5GB_SHIFT 0x0
#define VIRTCHNL_LINK_SPEED_100MB_SHIFT 0x1
#define VIRTCHNL_LINK_SPEED_1000MB_SHIFT 0x2
#define VIRTCHNL_LINK_SPEED_10GB_SHIFT 0x3
#define VIRTCHNL_LINK_SPEED_40GB_SHIFT 0x4
#define VIRTCHNL_LINK_SPEED_20GB_SHIFT 0x5
#define VIRTCHNL_LINK_SPEED_25GB_SHIFT 0x6
+#define VIRTCHNL_LINK_SPEED_5GB_SHIFT 0x7
enum virtchnl_link_speed {
VIRTCHNL_LINK_SPEED_UNKNOWN = 0,
@@ -76,6 +78,8 @@ enum virtchnl_link_speed {
VIRTCHNL_LINK_SPEED_40GB = BIT(VIRTCHNL_LINK_SPEED_40GB_SHIFT),
VIRTCHNL_LINK_SPEED_20GB = BIT(VIRTCHNL_LINK_SPEED_20GB_SHIFT),
VIRTCHNL_LINK_SPEED_25GB = BIT(VIRTCHNL_LINK_SPEED_25GB_SHIFT),
+ VIRTCHNL_LINK_SPEED_2_5GB = BIT(VIRTCHNL_LINK_SPEED_2_5GB_SHIFT),
+ VIRTCHNL_LINK_SPEED_5GB = BIT(VIRTCHNL_LINK_SPEED_5GB_SHIFT),
};
/* for hsplit_0 field of Rx HMC context */
--
2.21.0
^ permalink raw reply related
* [net-next 01/10] ixgbe: Check DDM existence in transceiver before access
From: Jeff Kirsher @ 2019-06-26 19:30 UTC (permalink / raw)
To: davem
Cc: Mauro S. M. Rodrigues, netdev, nhorman, sassmann,
Jesse Brandeburg, Andrew Bowers, Jeff Kirsher
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: "Mauro S. M. Rodrigues" <maurosr@linux.vnet.ibm.com>
Some transceivers may comply with SFF-8472 but not implement the Digital
Diagnostic Monitoring (DDM) interface described in it. The existence of
such area is specified by bit 6 of byte 92, set to 1 if implemented.
Currently, due to not checking this bit ixgbe fails trying to read SFP
module's eeprom with the follow message:
ethtool -m enP51p1s0f0
Cannot get Module EEPROM data: Input/output error
Because it fails to read the additional 256 bytes in which it was assumed
to exist the DDM data.
This issue was noticed using a Mellanox Passive DAC PN 01FT738. The eeprom
data was confirmed by Mellanox as correct and present in other Passive
DACs in from other manufacturers.
Signed-off-by: "Mauro S. M. Rodrigues" <maurosr@linux.vnet.ibm.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@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_ethtool.c | 3 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index acba067cc15a..7c52ae8ac005 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -3226,7 +3226,8 @@ static int ixgbe_get_module_info(struct net_device *dev,
page_swap = true;
}
- if (sff8472_rev == IXGBE_SFF_SFF_8472_UNSUP || page_swap) {
+ if (sff8472_rev == IXGBE_SFF_SFF_8472_UNSUP || page_swap ||
+ !(addr_mode & IXGBE_SFF_DDM_IMPLEMENTED)) {
/* We have a SFP, but it does not support SFF-8472 */
modinfo->type = ETH_MODULE_SFF_8079;
modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
index 214b01085718..6544c4539c0d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
@@ -45,6 +45,7 @@
#define IXGBE_SFF_SOFT_RS_SELECT_10G 0x8
#define IXGBE_SFF_SOFT_RS_SELECT_1G 0x0
#define IXGBE_SFF_ADDRESSING_MODE 0x4
+#define IXGBE_SFF_DDM_IMPLEMENTED 0x40
#define IXGBE_SFF_QSFP_DA_ACTIVE_CABLE 0x1
#define IXGBE_SFF_QSFP_DA_PASSIVE_CABLE 0x8
#define IXGBE_SFF_QSFP_CONNECTOR_NOT_SEPARABLE 0x23
--
2.21.0
^ permalink raw reply related
* Re: [PATCH bpf-next v8 1/9] bpf: implement getsockopt and setsockopt hooks
From: Alexei Starovoitov @ 2019-06-26 19:21 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Stanislav Fomichev, netdev, bpf, davem, ast, daniel, Martin Lau
In-Reply-To: <20190626191021.GB4866@mini-arch>
On Wed, Jun 26, 2019 at 12:10:21PM -0700, Stanislav Fomichev wrote:
> On 06/26, Alexei Starovoitov wrote:
> > On Mon, Jun 24, 2019 at 09:24:21AM -0700, Stanislav Fomichev wrote:
> > > Implement new BPF_PROG_TYPE_CGROUP_SOCKOPT program type and
> > > BPF_CGROUP_{G,S}ETSOCKOPT cgroup hooks.
> > >
> > > BPF_CGROUP_SETSOCKOPT get a read-only view of the setsockopt arguments.
> > > BPF_CGROUP_GETSOCKOPT can modify the supplied buffer.
> > > Both of them reuse existing PTR_TO_PACKET{,_END} infrastructure.
> >
> > getsockopt side looks good to me.
> > I tried to convince myself that readonly setsockopt is fine for now,
> > but it feels we need to make it writeable from the start.
> > I agree with your reasoning that doing copy_to_user is no good,
> > but we can do certainly do set_fs(KERNEL_DS) game.
> > The same way as kernel_setsockopt() is doing.
> > It seems quite useful to modify 'optval' before passing it to kernel.
> > Then bpf prog would be able to specify sane values for SO_SNDBUF
> > instead of rejecting them.
> > The alternative would be to allow bpf prog to call setsockopt
> > from inside, but sock is locked when prog is running,
> > so unlocking within helper is not going to be clean.
> > wdyt?
> Sure, I can take a look if you think that it would be useful in general.
> Looks like set_fs should do the trick.
Thanks. I think it's useful.
For example see the recent sack steam issue and Eric's workaround
for older kernel to add 128k to sk_sndbuf.
If we had an ability to do adjust SO_SNDBUF from cgroup-bpf prog
when user space is doing setsockopt we could have mitigated it by
rolling bpf prog instead of patching and rebooting the kernels.
That's a bit of a stretch use case, of course.
My feeling that if not today, but really soon people will find
solid use cases for adjusting sockopt values via cgroup-bpf.
^ permalink raw reply
* Re: [PATCH 2/3 nf-next] netfilter:nf_flow_table: Support bridge type flow offload
From: Florian Westphal @ 2019-06-26 19:19 UTC (permalink / raw)
To: Florian Westphal; +Cc: wenxu, pablo, netfilter-devel, netdev
In-Reply-To: <20190626183816.3ux3iifxaal4ffil@breakpoint.cc>
Florian Westphal <fw@strlen.de> wrote:
> wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
> > diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
> > index 0016bb8..9af01ef 100644
> > --- a/net/netfilter/nf_flow_table_ip.c
> > +++ b/net/netfilter/nf_flow_table_ip.c
> > - neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb);
> > + if (family == NFPROTO_IPV4) {
> > + iph = ip_hdr(skb);
> > + ip_decrease_ttl(iph);
> > +
> > + nexthop = rt_nexthop(rt, flow->tuplehash[!dir].tuple.src_v4.s_addr);
> > + skb_dst_set_noref(skb, &rt->dst);
> > + neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb);
> > + } else {
> > + const struct net_bridge_port *p;
> > +
> > + if (vlan_tag && (p = br_port_get_rtnl_rcu(state->in)))
> > + __vlan_hwaccel_put_tag(skb, p->br->vlan_proto, vlan_tag);
> > + else
> > + __vlan_hwaccel_clear_tag(skb);
> > +
> > + br_dev_queue_push_xmit(state->net, state->sk, skb);
>
> Won't that result in a module dep on bridge?
>
> Whats the idea with this patch?
>
> Do you see a performance improvement when bypassing bridge layer? If so,
> how much?
>
> I just wonder if its really cheaper than not using bridge conntrack in
> the first place :-)
Addendum: Did you look at the nftables fwd expression? Maybe you can use
it as a simpler way to speed things up?
^ permalink raw reply
* Re: [PATCH net-next] gso: enable udp gso for virtual devices
From: Jason Baron @ 2019-06-26 19:15 UTC (permalink / raw)
To: Willem de Bruijn, Alexander Duyck
Cc: David Miller, Netdev, Joshua Hunt, Willem de Bruijn, Paolo Abeni
In-Reply-To: <f91fb37a-379a-4a59-7e04-cf8a6d161efa@akamai.com>
On 6/14/19 4:53 PM, Jason Baron wrote:
>
>
> On 6/13/19 5:20 PM, Willem de Bruijn wrote:
>>>>> @@ -237,6 +237,7 @@ static inline int find_next_netdev_feature(u64 feature, unsigned long start)
>>>>> NETIF_F_GSO_GRE_CSUM | \
>>>>> NETIF_F_GSO_IPXIP4 | \
>>>>> NETIF_F_GSO_IPXIP6 | \
>>>>> + NETIF_F_GSO_UDP_L4 | \
>>>>> NETIF_F_GSO_UDP_TUNNEL | \
>>>>> NETIF_F_GSO_UDP_TUNNEL_CSUM)
>>>>
>>>> Are you adding this to NETIF_F_GSO_ENCAP_ALL? Wouldn't it make more
>>>> sense to add it to NETIF_F_GSO_SOFTWARE?
>>>>
>>>
>>> Yes, I'm adding to NETIF_F_GSO_ENCAP_ALL (not very clear from the
>>> context). I will fix the commit log.
>>>
>>> In: 83aa025 udp: add gso support to virtual devices, the support was
>>> also added to NETIF_F_GSO_ENCAP_ALL (although subsequently reverted due
>>> to UDP GRO not being in place), so I wonder what the reason was for that?
>>
>> That was probably just a bad choice on my part.
>>
>> It worked in practice, but if NETIF_F_GSO_SOFTWARE works the same
>> without unexpected side effects, then I agree that it is the better choice.
>>
>> That choice does appear to change behavior when sending over tunnel
>> devices. Might it send tunneled GSO packets over loopback?
>>
>>
>
> I set up a test case using fou tunneling through a bridge device using
> the udpgso_bench_tx test where packets are not received correctly if
> NETIF_F_GSO_UDP_L4 is added to NETIF_F_GSO_SOFTWARE. If I have it added
> to NETIF_F_GSO_ENCAP_ALL, it does work correctly. So there are more
> fixes required to include it in NETIF_F_GSO_SOFTWARE.
>
> The use-case I have only requires it to be in NETIF_F_GSO_ENCAP_ALL, but
> if it needs to go in NETIF_F_GSO_SOFTWARE, I can look at what's required
> more next week.
>
Hi,
I haven't had a chance to investigate what goes wrong with including
NETIF_F_GSO_UDP_L4 in NETIF_F_GSO_SOFTWARE - but I was just wondering if
people are ok with NETIF_F_GSO_UDP_L4 being added to
NETIF_F_GSO_ENCAP_ALL and not NETIF_F_GSO_SOFTWARE (ie the original
patch as posted)?
As I mentioned that is sufficient for my use-case, and its how Willem
originally proposed this.
Thanks,
-Jason
> Thanks,
>
> -Jason
>
>>
>>> I agree that NETIF_F_GSO_SOFTWARE seems conceptually more logical and
>>> further I think it adds support for more 'virtual' devices. For example,
>>> I tested loopback with NETIF_F_GSO_UDP_L4 being added to
>>> NETIF_F_GSO_SOFTWARE and it shows a nice performance gain, whereas
>>> NETIF_F_GSO_ENCAP_ALL isn't included for loopback.
>>>
>>> Thanks,
>>>
>>> -Jason
^ permalink raw reply
* Re: [PATCH bpf-next v8 1/9] bpf: implement getsockopt and setsockopt hooks
From: Stanislav Fomichev @ 2019-06-26 19:10 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Stanislav Fomichev, netdev, bpf, davem, ast, daniel, Martin Lau
In-Reply-To: <20190626185420.wzsb7v6rawn4wtzd@ast-mbp.dhcp.thefacebook.com>
On 06/26, Alexei Starovoitov wrote:
> On Mon, Jun 24, 2019 at 09:24:21AM -0700, Stanislav Fomichev wrote:
> > Implement new BPF_PROG_TYPE_CGROUP_SOCKOPT program type and
> > BPF_CGROUP_{G,S}ETSOCKOPT cgroup hooks.
> >
> > BPF_CGROUP_SETSOCKOPT get a read-only view of the setsockopt arguments.
> > BPF_CGROUP_GETSOCKOPT can modify the supplied buffer.
> > Both of them reuse existing PTR_TO_PACKET{,_END} infrastructure.
>
> getsockopt side looks good to me.
> I tried to convince myself that readonly setsockopt is fine for now,
> but it feels we need to make it writeable from the start.
> I agree with your reasoning that doing copy_to_user is no good,
> but we can do certainly do set_fs(KERNEL_DS) game.
> The same way as kernel_setsockopt() is doing.
> It seems quite useful to modify 'optval' before passing it to kernel.
> Then bpf prog would be able to specify sane values for SO_SNDBUF
> instead of rejecting them.
> The alternative would be to allow bpf prog to call setsockopt
> from inside, but sock is locked when prog is running,
> so unlocking within helper is not going to be clean.
> wdyt?
Sure, I can take a look if you think that it would be useful in general.
Looks like set_fs should do the trick.
(I was thinking about exporting something like the existing bpf_setsockopt
to a setsockopt hooks, but I agree, it comes with its own bag
of problems).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox