* Re: net: macb: Fix compilation on systems without COMMON_CLK, v2
From: David Miller @ 2019-06-26 21:09 UTC (permalink / raw)
To: palmer; +Cc: nicolas.ferre, harinik, netdev, linux-kernel
In-Reply-To: <20190625084828.540-1-palmer@sifive.com>
From: Palmer Dabbelt <palmer@sifive.com>
Date: Tue, 25 Jun 2019 01:48:26 -0700
> Our patch to add support for the FU540-C000 broke compilation on at
> least powerpc allyesconfig, which was found as part of the linux-next
> build regression tests. This must have somehow slipped through the
> cracks, as the patch has been reverted in linux-next for a while now.
> This patch applies on top of the offending commit, which is the only one
> I've even tried it on as I'm not sure how this subsystem makes it to
> Linus.
>
> This patch set fixes the issue by adding a dependency of COMMON_CLK to
> the MACB Kconfig entry, which avoids the build failure by disabling MACB
> on systems where it wouldn't compile. All known users of MACB have
> COMMON_CLK, so this shouldn't cause any issues. This is a significantly
> simpler approach than disabling just the FU540-C000 support.
>
> I've also included a second patch to indicate this is a driver for a
> Cadence device that was originally written by an engineer at Atmel. The
> only relation is that I stumbled across it when writing the first patch.
>
> Changes since v1 <20190624061603.1704-1-palmer@sifive.com>:
>
> * Disable MACB on systems without COMMON_CLK, instead of just disabling
> the FU540-C000 support on these systems.
> * Update the commit message to reflect the driver was written by Atmel.
Series applied, thanks.
^ permalink raw reply
* Re: INFO: rcu detected stall in ext4_write_checks
From: Theodore Ts'o @ 2019-06-26 21:03 UTC (permalink / raw)
To: syzbot, adilger.kernel, davem, eladr, idosch, jiri, john.stultz,
linux-ext4, linux-kernel, netdev, syzkaller-bugs, tglx
In-Reply-To: <20190626184251.GE3116@mit.edu>
The reproducer causes similar rcu stalls when using xfs:
RSP: 0018:ffffaae8c0953c58 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000288 RBX: 000000000000b05a RCX: ffffaae8c0953d50
RDX: 000000000000001c RSI: 000000000000001c RDI: ffffdcec41772800
RBP: ffffdcec41772800 R08: 00000015143ceae3 R09: 0000000000000001
R10: 0000000000000000 R11: ffffffff96863980 R12: ffff88d179ac7d80
R13: ffff88d174837ca0 R14: 0000000000000288 R15: 000000000000001c
generic_file_buffered_read+0x2c1/0x8b0
xfs_file_buffered_aio_read+0x5f/0x140
xfs_file_read_iter+0x6e/0xd0
generic_file_splice_read+0x110/0x1d0
splice_direct_to_actor+0xd5/0x230
? pipe_to_sendpage+0x90/0x90
do_splice_direct+0x9f/0xd0
do_sendfile+0x1d4/0x3a0
__se_sys_sendfile64+0x58/0xc0
do_syscall_64+0x50/0x1b0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f8038387469
and btrfs
[ 42.671321] RSP: 0018:ffff960dc0963b90 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
[ 42.673592] RAX: 0000000000000001 RBX: ffff89eb3628ab30 RCX: 00000000ffffffff
[ 42.675775] RDX: ffff89eb3628a380 RSI: 00000000ffffffff RDI: ffffffff9ec63980
[ 42.677851] RBP: ffff89eb3628aaf8 R08: 0000000000000001 R09: 0000000000000001
[ 42.680028] R10: 0000000000000000 R11: ffffffff9ec63980 R12: ffff89eb3628a380
[ 42.682213] R13: 0000000000000246 R14: 0000000000000001 R15: ffffffff9ec63980
[ 42.684509] xas_descend+0xed/0x120
[ 42.685682] xas_load+0x39/0x50
[ 42.686691] find_get_entry+0xa0/0x330
[ 42.687885] pagecache_get_page+0x30/0x2d0
[ 42.689190] generic_file_buffered_read+0xee/0x8b0
[ 42.690708] generic_file_splice_read+0x110/0x1d0
[ 42.692374] splice_direct_to_actor+0xd5/0x230
[ 42.693868] ? pipe_to_sendpage+0x90/0x90
[ 42.695180] do_splice_direct+0x9f/0xd0
[ 42.696407] do_sendfile+0x1d4/0x3a0
[ 42.697551] __se_sys_sendfile64+0x58/0xc0
[ 42.698854] do_syscall_64+0x50/0x1b0
[ 42.700021] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 42.701619] RIP: 0033:0x7f21e8d5f469
So this is probably a generic vfs issue (probably in sendfile). Next
steps is probably for someone to do a bisection search covering
changes to the fs/ and mm/ directories. This should exclude bogus
changes in the networking layer, although it does seem that there is
something very badly wrong which is breaking bisectability, if you
can't even scp to the system under test for certain commit ranges. :-( :-( :-(
- Ted
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] libbpf: add perf buffer abstraction and API
From: Toke Høiland-Jørgensen @ 2019-06-26 20:50 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, bpf,
Networking, Kernel Team
In-Reply-To: <CAEf4BzZozWBanXnjJguYT46v8huAS7Wz44MHFHJkAPBZbT-i6A@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Wed, Jun 26, 2019 at 4:55 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Andrii Nakryiko <andriin@fb.com> writes:
>>
>> > This patchset adds a high-level API for setting up and polling perf buffers
>> > associated with BPF_MAP_TYPE_PERF_EVENT_ARRAY map. Details of APIs are
>> > described in corresponding commit.
>> >
>> > Patch #1 adds a set of APIs to set up and work with perf buffer.
>> > Patch #2 enhances libbpf to supprot auto-setting PERF_EVENT_ARRAY map size.
>> > Patch #3 adds test.
>>
>> Having this in libbpf is great! Do you have a usage example of how a
>> program is supposed to read events from the buffer? This is something we
>> would probably want to add to the XDP tutorial
>
> Did you check patch #3 with selftest? It's essentially an end-to-end
> example of how to set everything up and process data (in my case it's
> just simple int being sent as a sample, but it's exactly the same with
> more complicated structs). I didn't bother to handle lost samples
> notification, but it's just another optional callback with a single
> counter denoting how many samples were dropped.
>
> Let me know if it's still unclear.
I did read the example, but I obviously did not grok how it was supposed
to work; re-reading it now it's quite clear, thanks! :)
-Toke
^ permalink raw reply
* Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems
From: Björn Töpel @ 2019-06-26 20:50 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Björn Töpel, Karlsson, Magnus, David Miller,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Netdev, bpf, Xdp, LKML
In-Reply-To: <20190626155911.13574-1-ivan.khoronzhuk@linaro.org>
On Wed, 26 Jun 2019 at 17:59, Ivan Khoronzhuk
<ivan.khoronzhuk@linaro.org> wrote:
>
> Use kmap instead of page_address as it's not always in low memory.
>
Ah, some 32-bit love. :-) Thanks for working on this!
For future patches, please base AF_XDP patches on the bpf/bpf-next
tree instead of net/net-next.
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> net/xdp/xdp_umem.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 9c6de4f114f8..d3c1411420fd 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -169,6 +169,14 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> }
> }
>
> +static void xdp_umem_unmap_pages(struct xdp_umem *umem)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < umem->npgs; i++)
> + kunmap(umem->pgs[i]);
> +}
> +
> static void xdp_umem_unpin_pages(struct xdp_umem *umem)
> {
> unsigned int i;
> @@ -210,6 +218,7 @@ static void xdp_umem_release(struct xdp_umem *umem)
>
> xsk_reuseq_destroy(umem);
>
> + xdp_umem_unmap_pages(umem);
> xdp_umem_unpin_pages(umem);
>
> kfree(umem->pages);
> @@ -372,7 +381,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
> }
>
> for (i = 0; i < umem->npgs; i++)
> - umem->pages[i].addr = page_address(umem->pgs[i]);
> + umem->pages[i].addr = kmap(umem->pgs[i]);
>
> return 0;
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: ipv4: remove erroneous advancement of list pointer
From: Florian Westphal @ 2019-06-26 20:37 UTC (permalink / raw)
To: Ran Rozenstein
Cc: Florian Westphal, Tariq Toukan, netdev@vger.kernel.org,
Maor Gottlieb, edumazet@google.com
In-Reply-To: <AM4PR0501MB2769CE8DC11EE4A076B62CCCC5E20@AM4PR0501MB2769.eurprd05.prod.outlook.com>
Ran Rozenstein <ranro@mellanox.com> wrote:
> The test dose stress on the interface by running this 2 commands in loop:
>
> command is: /sbin/ip -f inet addr add $IP/16 brd + dev ens8f1
> command is: ifconfig ens8f1 $IP netmask 255.255.0.0
>
> when $IP change every iteration.
>
> It execute every second when we see the reproduce somewhere between 40 to 200 seconds of execution.
I tried this without success:
DEV=dummy0
for j in $(seq 2 254);do
for i in $(seq 2 254);do
IP="10.$((RANDOM%254)).$((RANDOM%254)).$i"
ip -f inet addr add $IP/16 brd + dev $DEV
ifconfig $DEV $IP netmask 255.255.0.0
done
done
I'll let this loop overnight, but so far nothing turned up in
dmesg (lockdep/kasan kernel).
^ permalink raw reply
* Re: [PATCH bpf-next V6 00/16] AF_XDP infrastructure improvements and mlx5e support
From: Daniel Borkmann @ 2019-06-26 20:26 UTC (permalink / raw)
To: Tariq Toukan, Alexei Starovoitov, bjorn.topel, Magnus Karlsson
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Jonathan Lemon,
David S. Miller, Maxim Mikityanskiy
In-Reply-To: <1561559738-4213-1-git-send-email-tariqt@mellanox.com>
On 06/26/2019 04:35 PM, Tariq Toukan wrote:
[...]
> v6 changes:
>
> As Maxim is out of office, I rebased the series on behalf of him,
> solved some conflicts, and re-spinned.
Thanks for taking over the rebase, Tariq!
> Series generated against bpf-next commit:
> 572a6928f9e3 xdp: Make __mem_id_disconnect static
>
>
> Maxim Mikityanskiy (16):
> net/mlx5e: Attach/detach XDP program safely
> xsk: Add API to check for available entries in FQ
> xsk: Add getsockopt XDP_OPTIONS
> libbpf: Support getsockopt XDP_OPTIONS
> xsk: Change the default frame size to 4096 and allow controlling it
> xsk: Return the whole xdp_desc from xsk_umem_consume_tx
> net/mlx5e: Replace deprecated PCI_DMA_TODEVICE
> net/mlx5e: Calculate linear RX frag size considering XSK
> net/mlx5e: Allow ICO SQ to be used by multiple RQs
> net/mlx5e: Refactor struct mlx5e_xdp_info
> net/mlx5e: Share the XDP SQ for XDP_TX between RQs
> net/mlx5e: XDP_TX from UMEM support
> net/mlx5e: Consider XSK in XDP MTU limit calculation
> net/mlx5e: Encapsulate open/close queues into a function
> net/mlx5e: Move queue param structs to en/params.h
> net/mlx5e: Add XSK zero-copy support
Series applied, thanks!
^ permalink raw reply
* 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
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