* Re: [PATCH net v2 0/2] ipv6: fix neighbour resolution with raw socket
From: David Miller @ 2019-06-26 20:26 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, ndesaulniers
In-Reply-To: <20190624140109.14775-1-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 24 Jun 2019 16:01:07 +0200
> The first patch prepares the fix, it constify rt6_nexthop().
> The detail of the bug is explained in the second patch.
>
> v1 -> v2:
> - fix compilation warnings
> - split the initial patch
Series applied, thanks Nicolas.
^ permalink raw reply
* Re: [EXT] [PATCH V2] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: Guilherme Piccoli @ 2019-06-26 20:24 UTC (permalink / raw)
To: Sudarsana Reddy Kalluru
Cc: jay.vosburgh@canonical.com, GR-everest-linux-l2,
netdev@vger.kernel.org, Ariel Elior
In-Reply-To: <MN2PR18MB2528569269272880338B8E4CD3E20@MN2PR18MB2528.namprd18.prod.outlook.com>
On Wed, Jun 26, 2019 at 5:25 AM Sudarsana Reddy Kalluru
<skalluru@marvell.com> wrote:
> > Sudarsana, let me ask you something: why does the register is reading value
> > 0x0 always in the TX timestamp routine if the RX filter is set to None? This is
> > the main cause of the thread reschedule thing.
>
> The register value of zero indicates there is no pending Tx timestamp to be read by the driver.
> FW writes/latches the Tx timestamp for PTP event packet in this register. And it does the latching only if the register is free.
> In this case user/app look to be requesting the Timestamp (via skb->tx_flags) for non-ptp Tx packet. In the Tx path, driver schedules a thread for reading the Tx timestamp,
> bnx2x_start_xmit()
> {
> if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP))
> schedule_work(&bp->ptp_task);
> }
> FW seem to be not timestamping the packet at all and driver is indefinitely waiting for it.
>
Thanks Sudarsana! I've tried to implement the qede-like approach
again, with the 2s timeout before
bailing-out the thread reschedule. This time, I've remove _all_log
messages, including the DP() ones...
Unfortunately kthread is still consuming 100% of CPU, which makes
sense, since it reschedules itself
the most times it can in this 2s window...I think we really should
have small pauses before retrying to
read the registers. I've worked a V3, implementing 1ms-starting
pauses, which worked well:
https://marc.info/?l=linux-netdev&m=156158032618932
I hope this way we don't harm the PTP applications, nor introduce
delays in the FW wait-queue,
and at same time we can fix the indefinitely reschedule in bnx2x.
Thanks again for your support,
Guilherme
^ permalink raw reply
* Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: James Morris @ 2019-06-26 20:22 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Matthew Garrett, linux-security, LKML, Linux API, David Howells,
Alexei Starovoitov, Matthew Garrett, Network Development,
Chun-Yi Lee, Daniel Borkmann, linux-security-module
In-Reply-To: <CALCETrVUwQP7roLnW6kFG80Cc5U6X_T6AW+BTAftLccYGp8+Ow@mail.gmail.com>
[Adding the LSM mailing list: missed this patchset initially]
On Thu, 20 Jun 2019, Andy Lutomirski wrote:
> This patch exemplifies why I don't like this approach:
>
> > @@ -97,6 +97,7 @@ enum lockdown_reason {
> > LOCKDOWN_INTEGRITY_MAX,
> > LOCKDOWN_KCORE,
> > LOCKDOWN_KPROBES,
> > + LOCKDOWN_BPF,
> > LOCKDOWN_CONFIDENTIALITY_MAX,
>
> > --- a/security/lockdown/lockdown.c
> > +++ b/security/lockdown/lockdown.c
> > @@ -33,6 +33,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> > [LOCKDOWN_INTEGRITY_MAX] = "integrity",
> > [LOCKDOWN_KCORE] = "/proc/kcore access",
> > [LOCKDOWN_KPROBES] = "use of kprobes",
> > + [LOCKDOWN_BPF] = "use of bpf",
> > [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
>
> The text here says "use of bpf", but what this patch is *really* doing
> is locking down use of BPF to read kernel memory. If the details
> change, then every LSM needs to get updated, and we risk breaking user
> policies that are based on LSMs that offer excessively fine
> granularity.
Can you give an example of how the details might change?
> I'd be more comfortable if the LSM only got to see "confidentiality"
> or "integrity".
These are not sufficient for creating a useful policy for the SELinux
case.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH V2] net: dsa: microchip: Use gpiod_set_value_cansleep()
From: David Miller @ 2019-06-26 20:23 UTC (permalink / raw)
To: marex; +Cc: netdev, andrew, f.fainelli, linus.walleij, Tristram.Ha,
Woojung.Huh
In-Reply-To: <20190623151257.13660-1-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Sun, 23 Jun 2019 17:12:57 +0200
> Replace gpiod_set_value() with gpiod_set_value_cansleep(), as the switch
> reset GPIO can be connected to e.g. I2C GPIO expander and it is perfectly
> fine for the kernel to sleep for a bit in ksz_switch_register().
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> Cc: Woojung Huh <Woojung.Huh@microchip.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
> V2: use _cansleep in .remove as well
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/1] Allow 0.0.0.0/8 as a valid address range
From: David Miller @ 2019-06-26 20:20 UTC (permalink / raw)
To: dave.taht; +Cc: netdev, gnu
In-Reply-To: <1561223254-13589-2-git-send-email-dave.taht@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 22 Jun 2019 10:07:34 -0700
> The longstanding prohibition against using 0.0.0.0/8 dates back
> to two issues with the early internet.
>
> There was an interoperability problem with BSD 4.2 in 1984, fixed in
> BSD 4.3 in 1986. BSD 4.2 has long since been retired.
>
> Secondly, addresses of the form 0.x.y.z were initially defined only as
> a source address in an ICMP datagram, indicating "node number x.y.z on
> this IPv4 network", by nodes that know their address on their local
> network, but do not yet know their network prefix, in RFC0792 (page
> 19). This usage of 0.x.y.z was later repealed in RFC1122 (section
> 3.2.2.7), because the original ICMP-based mechanism for learning the
> network prefix was unworkable on many networks such as Ethernet (which
> have longer addresses that would not fit into the 24 "node number"
> bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951)
> or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask
> (and other parameters such as default gateways). 0.x.y.z has had
> 16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for
> future use, since 1989.
>
> This patch allows for these 16m new IPv4 addresses to appear within
> a box or on the wire. Layer 2 switches don't care.
>
> 0.0.0.0/32 is still prohibited, of course.
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
> Signed-off-by: John Gilmore <gnu@toad.com>
> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Applied, thanks for following up on this.
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: stmmac: Enable support for > 32 Bits addressing in XGMAC
From: Andrew Lunn @ 2019-06-26 20:19 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel, netdev, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <64b73591f981b3a280ea61d21a0dc7362a25348a.1561556556.git.joabreu@synopsys.com>
> +
> + if (priv->dma_cap.addr64) {
> + ret = dma_set_mask_and_coherent(device,
> + DMA_BIT_MASK(priv->dma_cap.addr64));
> + if (!ret)
> + dev_info(priv->device, "Using %d bits DMA width\n",
> + priv->dma_cap.addr64);
> + }
Hi Jose
If dma_set_mask_and_coherent() fails, i think you are supposed to fall
back to 32 bits. So you might want to clear priv->dma_cap.addr64.
But don't trust my, i could be wrong.
Andrew
^ permalink raw reply
* [PATCH V3] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: Guilherme G. Piccoli @ 2019-06-26 20:18 UTC (permalink / raw)
To: GR-everest-linux-l2, netdev, skalluru; +Cc: aelior, gpiccoli, jay.vosburgh
Currently bnx2x ptp worker tries to read a register with timestamp
information in case of TX packet timestamping and in case it fails,
the routine reschedules itself indefinitely. This was reported as a
kworker always at 100% of CPU usage, which was narrowed down to be
bnx2x ptp_task.
By following the ioctl handler, we could narrow down the problem to
an NTP tool (chrony) requesting HW timestamping from bnx2x NIC with
RX filter zeroed; this isn't reproducible for example with ptp4l
(from linuxptp) since this tool requests a supported RX filter.
It seems NIC FW timestamp mechanism cannot work well with
RX_FILTER_NONE - driver's PTP filter init routine skips a register
write to the adapter if there's not a supported filter request.
This patch addresses the problem of bnx2x ptp thread's everlasting
reschedule by retrying the register read 10 times; between the read
attempts the thread sleeps for an increasing amount of time starting
in 1ms to give FW some time to perform the timestamping. If it still
fails after all retries, we bail out in order to prevent an unbound
resource consumption from bnx2x.
The patch also adds an ethtool statistic for accounting the skipped
TX timestamp packets and it reduces the priority of timestamping
error messages to prevent log flooding. The code was tested using
both linuxptp and chrony.
Reported-and-tested-by: Przemyslaw Hausman <przemyslaw.hausman@canonical.com>
Suggested-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
---
Sudarsana, thanks again for your feedback. I've reduced the sleep times
to start in 1ms and goes up to 512ms - the sum of sleep times is 1023ms,
but due to the inherent overhead in sleeping/waking-up procedure, I've
measured the total delay in the register read loop (on bnx2x_ptp_task)
to be ~1.6 seconds. It is almost the 2s value you first suggested as
PTP_TIMEOUT.
.../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 12 +++++--
.../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 4 ++-
.../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 36 ++++++++++++++-----
.../net/ethernet/broadcom/bnx2x/bnx2x_stats.h | 3 ++
4 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 008ad0ca89ba..6751cd04e8d8 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3857,9 +3857,17 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
if (!(bp->flags & TX_TIMESTAMPING_EN)) {
- BNX2X_ERR("Tx timestamping was not enabled, this packet will not be timestamped\n");
+ bp->eth_stats.ptp_skip_tx_ts++;
+ netdev_err_once(bp->dev,
+ "Tx timestamping isn't enabled, this packet won't be timestamped\n");
+ DP(BNX2X_MSG_PTP,
+ "Tx timestamping isn't enabled, this packet won't be timestamped\n");
} else if (bp->ptp_tx_skb) {
- BNX2X_ERR("The device supports only a single outstanding packet to timestamp, this packet will not be timestamped\n");
+ bp->eth_stats.ptp_skip_tx_ts++;
+ netdev_err_once(bp->dev,
+ "Device supports only a single outstanding packet to timestamp, this packet won't be timestamped\n");
+ DP(BNX2X_MSG_PTP,
+ "Device supports only a single outstanding packet to timestamp, this packet won't be timestamped\n");
} else {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
/* schedule check for Tx timestamp */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 51fc845de31a..4a0ba6801c9e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -182,7 +182,9 @@ static const struct {
{ STATS_OFFSET32(driver_filtered_tx_pkt),
4, false, "driver_filtered_tx_pkt" },
{ STATS_OFFSET32(eee_tx_lpi),
- 4, true, "Tx LPI entry count"}
+ 4, true, "Tx LPI entry count"},
+ { STATS_OFFSET32(ptp_skip_tx_ts),
+ 4, false, "ptp_skipped_tx_tstamp" },
};
#define BNX2X_NUM_STATS ARRAY_SIZE(bnx2x_stats_arr)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 03ac10b1cd1e..af6e7a950a28 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -15214,11 +15214,27 @@ static void bnx2x_ptp_task(struct work_struct *work)
u32 val_seq;
u64 timestamp, ns;
struct skb_shared_hwtstamps shhwtstamps;
+ bool bail = true;
+ int i;
- /* Read Tx timestamp registers */
- val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
- NIG_REG_P0_TLLH_PTP_BUF_SEQID);
- if (val_seq & 0x10000) {
+ /* FW may take a while to complete timestamping; try a bit and if it's
+ * still not complete, may indicate an error state - bail out then.
+ */
+ for (i = 0; i < 10; i++) {
+ /* Read Tx timestamp registers */
+ val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
+ NIG_REG_P0_TLLH_PTP_BUF_SEQID);
+ if (val_seq & 0x10000) {
+ bail = false;
+ break;
+ }
+
+ if (!(i % 4)) /* Avoid log flood */
+ DP(BNX2X_MSG_PTP, "There's no valid Tx timestamp yet\n");
+ msleep(1 << i);
+ }
+
+ if (!bail) {
/* There is a valid timestamp value */
timestamp = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_TS_MSB :
NIG_REG_P0_TLLH_PTP_BUF_TS_MSB);
@@ -15233,16 +15249,18 @@ static void bnx2x_ptp_task(struct work_struct *work)
memset(&shhwtstamps, 0, sizeof(shhwtstamps));
shhwtstamps.hwtstamp = ns_to_ktime(ns);
skb_tstamp_tx(bp->ptp_tx_skb, &shhwtstamps);
- dev_kfree_skb_any(bp->ptp_tx_skb);
- bp->ptp_tx_skb = NULL;
DP(BNX2X_MSG_PTP, "Tx timestamp, timestamp cycles = %llu, ns = %llu\n",
timestamp, ns);
} else {
- DP(BNX2X_MSG_PTP, "There is no valid Tx timestamp yet\n");
- /* Reschedule to keep checking for a valid timestamp value */
- schedule_work(&bp->ptp_task);
+ DP(BNX2X_MSG_PTP,
+ "Tx timestamp is not recorded (register read=%u)\n",
+ val_seq);
+ bp->eth_stats.ptp_skip_tx_ts++;
}
+
+ dev_kfree_skb_any(bp->ptp_tx_skb);
+ bp->ptp_tx_skb = NULL;
}
void bnx2x_set_rx_ts(struct bnx2x *bp, struct sk_buff *skb)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
index b2644ed13d06..d55e63692cf3 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
@@ -207,6 +207,9 @@ struct bnx2x_eth_stats {
u32 driver_filtered_tx_pkt;
/* src: Clear-on-Read register; Will not survive PMF Migration */
u32 eee_tx_lpi;
+
+ /* PTP */
+ u32 ptp_skip_tx_ts;
};
struct bnx2x_eth_q_stats {
--
2.22.0
^ permalink raw reply related
* Re: [PATCH net] net: aquantia: fix vlans not working over bridged network
From: David Miller @ 2019-06-26 20:17 UTC (permalink / raw)
To: Igor.Russkikh; +Cc: netdev, Dmitry.Bogdanov
In-Reply-To: <f9ccf4959d8efed1ee8832c56c59f5adfe2f9fd7.1561028841.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <Igor.Russkikh@aquantia.com>
Date: Sat, 22 Jun 2019 08:46:37 +0000
> From: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
>
> In configuration of vlan over bridge over aquantia device
> it was found that vlan tagged traffic is dropped on chip.
>
> The reason is that bridge device enables promisc mode,
> but in atlantic chip vlan filters will still apply.
> So we have to corellate promisc settings with vlan configuration.
>
> The solution is to track in a separate state variable the
> need of vlan forced promisc. And also consider generic
> promisc configuration when doing vlan filter config.
>
> Fixes: 7975d2aff5af ("net: aquantia: add support of rx-vlan-filter offload")
> Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: skip metrics loop for dst_default_metrics
From: David Miller @ 2019-06-26 20:15 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20190621232716.26755-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Fri, 21 Jun 2019 16:27:16 -0700
> From: David Ahern <dsahern@gmail.com>
>
> dst_default_metrics has all of the metrics initialized to 0, so nothing
> will be added to the skb in rtnetlink_put_metrics. Avoid the loop if
> metrics is from dst_default_metrics.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, thanks David.
^ permalink raw reply
* Re: [PATCH 3/3] net: ethernet: atheros: atlx: Remove unused and private PCI definitions
From: David Miller @ 2019-06-26 20:07 UTC (permalink / raw)
To: puranjay12
Cc: skhan, bjorn, netdev, linux-kernel, linux-kernel-mentees,
linux-pci
In-Reply-To: <20190621163921.26188-4-puranjay12@gmail.com>
From: Puranjay Mohan <puranjay12@gmail.com>
Date: Fri, 21 Jun 2019 22:09:21 +0530
> Remove unused private PCI definitions from skfbi.h because generic PCI
> symbols are already included from pci_regs.h.
>
> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Please also handle the PCI register bit value define duplications as well,
as pointed out by Bjorn.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v6 1/8] igb: clear out skb->tstamp after reading the txtime
From: Patel, Vedang @ 2019-06-26 20:06 UTC (permalink / raw)
To: Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, David Miller, Jamal Hadi Salim, Cong Wang,
Jiri Pirko, intel-wired-lan@lists.osuosl.org, Gomes, Vinicius,
l@dorileo.org, Jakub Kicinski, Murali Karicheri, Sergei Shtylyov,
Eric Dumazet, Brown, Aaron F
In-Reply-To: <4f0681155a6057bf40e281bfc251aba60c296201.camel@intel.com>
Hi Jeff,
> On Jun 26, 2019, at 12:44 PM, Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com> wrote:
>
> 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.
This patch is needed for ptp4l to function properly when txtime-assist mode is enabled. So, dropping this patch will break the series. When are you planning to submit the next set of updates to Dave? If a new version is needed, I can plan to send it out after you send your updates.
Thanks,
Vedang
^ permalink raw reply
* Re: [PATCH v5 0/3] net: fddi: skfp: Use PCI generic definitions instead of private duplicates
From: David Miller @ 2019-06-26 20:05 UTC (permalink / raw)
To: puranjay12
Cc: skhan, bjorn, netdev, linux-kernel, linux-kernel-mentees,
linux-pci, stephen
In-Reply-To: <20190621154037.25245-1-puranjay12@gmail.com>
From: Puranjay Mohan <puranjay12@gmail.com>
Date: Fri, 21 Jun 2019 21:10:34 +0530
> This patch series removes the private duplicates of PCI definitions in
> favour of generic definitions defined in pci_regs.h.
>
> This driver only uses some of the generic PCI definitons,
> which are included from pci_regs.h and thier private versions
> are removed from skfbi.h with all other private defines.
>
> The skfbi.h defines PCI_REV_ID and other private defines with different
> names, these are renamed to Generic PCI names to make them
> compatible with defines in pci_regs.h.
>
> All unused defines are removed from skfbi.h.
...
Series applied, thanks.
^ permalink raw reply
* 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
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