* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Saeed Mahameed @ 2019-07-23 20:34 UTC (permalink / raw)
To: davem@davemloft.net, leon@kernel.org
Cc: Jason Gunthorpe, Yishai Hadas, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, dledford@redhat.com, Edward Srouji
In-Reply-To: <20190723.130211.1967999203654051483.davem@davemloft.net>
On Tue, 2019-07-23 at 13:02 -0700, David Miller wrote:
> From: Leon Romanovsky <leon@kernel.org>
> Date: Tue, 23 Jul 2019 22:04:14 +0300
>
> > The intention was to have this patch in shared mlx5 branch, which
> > is
> > picked by RDMA too. This "Cc: stable@..." together with merge
> > through
> > RDMA will ensure that such patch will be part of stable
> > automatically.
>
> Why wouldn't it come via Saeed's usual mlx5 bug fix pull requests to
> me?
That should have been the plan in first place, i will handle this,
thanks Dave and sorry for any inconvenience.
I will apply this patch to my (mlx5) net queue, will submit to net
shortly.
Leon can merge the next -rc when this patch lands there.
meanwhile, Leon can also merge my (mlx5) net queue which is always
based on latest -rc.
https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/log/?h=net-mlx5
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: chip: Add of_node_put() before return
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
To: nishkadg.linux; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20190723104307.8068-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:13:07 +0530
> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a return from the middle of the loop, there is
> no put, thus causing a memory leak. Hence add an of_node_put before the
> return.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied, but as I've repeatedly stated these OF node looping constructs
are EXTREMELY ERROR PRONE.
We must fix these kinds of interfaces so that they are easier to use
correctly.
^ permalink raw reply
* Re: [PATCH] net: dsa: sja1105: sja1105_main: Add of_node_put()
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
To: nishkadg.linux
Cc: olteanv, andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190723104448.8125-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:14:48 +0530
> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied.
Again, the semantics of these looping constructs are terrible.
^ permalink raw reply
* Re: [PATCH net-next v2] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param
From: David Miller @ 2019-07-23 20:39 UTC (permalink / raw)
To: maximmi
Cc: arnd, ast, daniel, bpf, netdev, saeedm, leon, jakub.kicinski,
hawk, john.fastabend, tariqt
In-Reply-To: <20190723120208.27423-1-maximmi@mellanox.com>
From: Maxim Mikityanskiy <maximmi@mellanox.com>
Date: Tue, 23 Jul 2019 12:02:26 +0000
> From: Arnd Bergmann <arnd@arndb.de>
>
> The structure is too large to put on the stack, resulting in a
> warning on 32-bit ARM:
>
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:59:5: error: stack frame size of 1344 bytes in function
> 'mlx5e_open_xsk' [-Werror,-Wframe-larger-than=]
>
> Use kvzalloc() instead.
>
> Fixes: a038e9794541 ("net/mlx5e: Add XSK zero-copy support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> ---
> v2 changes: use kvzalloc/kvfree and fix a memory leak.
I'll apply this directly to net-next.
Thanks Maxim.
^ permalink raw reply
* Re: [bpf-next 6/6] selftests/bpf: add test for bpf_tcp_gen_syncookie
From: Alexei Starovoitov @ 2019-07-23 20:46 UTC (permalink / raw)
To: Lorenz Bauer
Cc: Petar Penkov, Networking, bpf, davem, Alexei Starovoitov,
Daniel Borkmann, Eric Dumazet, Stanislav Fomichev, Petar Penkov,
yhs
In-Reply-To: <CACAyw9-qQ8KbQk6Q6dg0+A337ZbSpot-sHpH_tSxFaQmUfhLyQ@mail.gmail.com>
On Tue, Jul 23, 2019 at 10:37:29AM +0100, Lorenz Bauer wrote:
> On Tue, 23 Jul 2019 at 01:20, Petar Penkov <ppenkov.kernel@gmail.com> wrote:
> > +static __always_inline __s64 gen_syncookie(void *data_end, struct bpf_sock *sk,
> > + void *iph, __u32 ip_size,
> > + struct tcphdr *tcph)
> > +{
> > + __u32 thlen = tcph->doff * 4;
> > +
> > + if (tcph->syn && !tcph->ack) {
> > + // packet should only have an MSS option
> > + if (thlen != 24)
> > + return 0;
>
> Just for my own understanding: without this the verifier complains since
> thlen is not a known value, even though it is in bounds due to the check below?
the verifier understands only constant part of the packet pointer.
Without additional 'if' above the statement:
if ((void *)tcph + thlen > data_end)
will add variables length 'thlen' to pkt pointer which will become
another pkt pointer (with different id).
That pointer would need 'pkt + const_range > data_end' to have valid access.
We hit this issue in the past when folks wanted to use bpf_csum_diff() helper
with variable size.
It's possible to extend the verifier to support that but it's intrusive,
since variable part would need to passed around to a bunch of check* functions.
I think it's tricky, but doable. Looking forward to patches :)
> > +
> > + if ((void *)tcph + thlen > data_end)
> > + return 0;
> > +
> > + return bpf_tcp_gen_syncookie(sk, iph, ip_size, tcph, thlen);
> > + }
> > + return 0;
> > +}
> > +
>
> --
> Lorenz Bauer | Systems Engineer
> 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
>
> www.cloudflare.com
^ permalink raw reply
* Re: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Saeed Mahameed @ 2019-07-23 20:49 UTC (permalink / raw)
To: claudiu.manoil@nxp.com, davem@davemloft.net
Cc: linux-arm-kernel@lists.infradead.org, leoyang.li@nxp.com,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
alexandru.marginean@nxp.com, robh+dt@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1563894955-545-2-git-send-email-claudiu.manoil@nxp.com>
On Tue, 2019-07-23 at 18:15 +0300, Claudiu Manoil wrote:
> ENETC ports can manage the MDIO bus via local register
> interface. However there's also a centralized way
> to manage the MDIO bus, via the MDIO PCIe endpoint
> device integrated by the same root complex that also
> integrates the ENETC ports (eth controllers).
>
> Depending on board design and use case, centralized
> access to MDIO may be better than using local ENETC
> port registers. For instance, on the LS1028A QDS board
> where MDIO muxing is requiered. Also, the LS1028A on-chip
> switch doesn't have a local MDIO register interface.
>
> The current patch registers the above PCIe enpoint as a
> separate MDIO bus and provides a driver for it by re-using
> the code used for local MDIO access. It also allows the
> ENETC port PHYs to be managed by this driver if the local
> "mdio" node is missing from the ENETC port node.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> .../net/ethernet/freescale/enetc/enetc_mdio.c | 90
> +++++++++++++++++++
> .../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
> 2 files changed, 94 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> index 77b9cd10ba2b..efa8a29f463d 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> @@ -197,3 +197,93 @@ void enetc_mdio_remove(struct enetc_pf *pf)
> mdiobus_free(pf->mdio);
> }
> }
> +
> +#define ENETC_MDIO_DEV_ID 0xee01
> +#define ENETC_MDIO_DEV_NAME "FSL PCIe IE Central MDIO"
> +#define ENETC_MDIO_BUS_NAME ENETC_MDIO_DEV_NAME " Bus"
> +#define ENETC_MDIO_DRV_NAME ENETC_MDIO_DEV_NAME " driver"
> +#define ENETC_MDIO_DRV_ID "fsl_enetc_mdio"
> +
> +static int enetc_pci_mdio_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + struct device *dev = &pdev->dev;
> + struct mii_bus *bus;
> + int err;
> +
> + bus = mdiobus_alloc_size(sizeof(u32 *));
> + if (!bus)
> + return -ENOMEM;
> +
> + bus->name = ENETC_MDIO_BUS_NAME;
> + bus->read = enetc_mdio_read;
> + bus->write = enetc_mdio_write;
> + bus->parent = dev;
> + snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
> +
> + pcie_flr(pdev);
> + err = pci_enable_device_mem(pdev);
> + if (err) {
> + dev_err(dev, "device enable failed\n");
mdiobus_free(bus) is missing here and in every error path.
> + return err;
> + }
> +
> + err = pci_request_mem_regions(pdev, ENETC_MDIO_DRV_ID);
> + if (err) {
> + dev_err(dev, "pci_request_regions failed\n");
> + goto err_pci_mem_reg;
> + }
> +
> + bus->priv = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
> + if (!bus->priv) {
> + err = -ENXIO;
> + dev_err(dev, "ioremap failed\n");
> + goto err_ioremap;
> + }
> +
> + err = of_mdiobus_register(bus, dev->of_node);
> + if (err)
> + goto err_mdiobus_reg;
> +
> + pci_set_drvdata(pdev, bus);
> +
> + return 0;
> +
> +err_mdiobus_reg:
> + iounmap(bus->priv);
> +err_ioremap:
> + pci_release_mem_regions(pdev);
> +err_pci_mem_reg:
> + pci_disable_device(pdev);
> +
> + return err;
> +}
> +
> +static void enetc_pci_mdio_remove(struct pci_dev *pdev)
> +{
> + struct mii_bus *bus = pci_get_drvdata(pdev);
> +
> + mdiobus_unregister(bus);
> + iounmap(bus->priv);
> + mdiobus_free(bus);
> +
this should come last to be symmetrical with probe flow.
> + pci_release_mem_regions(pdev);
> + pci_disable_device(pdev);
> +}
> +
> +static const struct pci_device_id enetc_pci_mdio_id_table[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, ENETC_MDIO_DEV_ID) },
> + { 0, } /* End of table. */
> +};
> +MODULE_DEVICE_TABLE(pci, enetc_mdio_id_table);
> +
> +static struct pci_driver enetc_pci_mdio_driver = {
> + .name = ENETC_MDIO_DRV_ID,
> + .id_table = enetc_pci_mdio_id_table,
> + .probe = enetc_pci_mdio_probe,
> + .remove = enetc_pci_mdio_remove,
> +};
> +module_pci_driver(enetc_pci_mdio_driver);
> +
> +MODULE_DESCRIPTION(ENETC_MDIO_DRV_NAME);
> +MODULE_LICENSE("Dual BSD/GPL");
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index 258b3cb38a6f..7d6513ff8507 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> @@ -750,6 +750,7 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
> {
> struct enetc_pf *pf = enetc_si_priv(priv->si);
> struct device_node *np = priv->dev->of_node;
> + struct device_node *mdio_np;
> int err;
>
> if (!np) {
> @@ -773,7 +774,9 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
> priv->phy_node = of_node_get(np);
> }
>
> - if (!of_phy_is_fixed_link(np)) {
> + mdio_np = of_get_child_by_name(np, "mdio");
> + if (mdio_np) {
> + of_node_put(mdio_np);
> err = enetc_mdio_probe(pf);
> if (err) {
> of_node_put(priv->phy_node);
^ permalink raw reply
* Re: [PATCH net-next 0/4] nfp: Offload MPLS actions
From: David Miller @ 2019-07-23 20:53 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1563892442-4654-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Tue, 23 Jul 2019 15:33:58 +0100
> The module act_mpls has recently been added to the kernel. This allows the
> manipulation of MPLS headers on packets including push, pop and modify.
> Add these new actions and parameters to the intermediate representation
> API for hardware offload. Follow this by implementing the offload of these
> MPLS actions in the NFP driver.
Looks nice, clean, and straightforward.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sky2: Disable MSI on ASUS P6T
From: David Miller @ 2019-07-23 20:55 UTC (permalink / raw)
To: tiwai; +Cc: netdev, mlindner, stephen, m.seyfarth
In-Reply-To: <20190723151525.6526-1-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 23 Jul 2019 17:15:25 +0200
> The onboard sky2 NIC on ASUS P6T WS PRO doesn't work after PM resume
> due to the infamous IRQ problem. Disabling MSI works around it, so
> let's add it to the blacklist.
>
> Unfortunately the BIOS on the machine doesn't fill the standard
> DMI_SYS_* entry, so we pick up DMI_BOARD_* entries instead.
>
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1142496
> Reported-and-tested-by: Marcus Seyfarth <m.seyfarth@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v1] hv_sock: Use consistent types for UUIDs
From: David Miller @ 2019-07-23 20:58 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: haiyangz, kys, sthemmin, sashal, linux-hyperv, netdev
In-Reply-To: <20190723163943.65991-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 19:39:43 +0300
> The rest of Hyper-V code is using new types for UUID handling.
> Convert hv_sock as well.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] dpaa2-eth: Don't use netif_receive_skb_list for TCP frames
From: David Miller @ 2019-07-23 21:02 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei, vladimir.oltean
In-Reply-To: <1563902923-26178-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Date: Tue, 23 Jul 2019 20:28:43 +0300
> Using Rx skb bulking for all frames may negatively impact the
> performance in some TCP termination scenarios, as it effectively
> bypasses GRO.
"may"?
Please provide numbers so that we know exactly whether it actually
hurts performance one way or another.
Thank you.
^ permalink raw reply
* Re: [net-next 6/6] e1000e: disable force K1-off feature
From: David Miller @ 2019-07-23 21:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: kai.heng.feng, netdev, nhorman, sassmann, aaron.f.brown
In-Reply-To: <20190723173650.23276-7-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 23 Jul 2019 10:36:50 -0700
> diff --git a/drivers/net/ethernet/intel/e1000e/hw.h b/drivers/net/ethernet/intel/e1000e/hw.h
> index eff75bd8a8f0..e3c71fd093ee 100644
> --- a/drivers/net/ethernet/intel/e1000e/hw.h
> +++ b/drivers/net/ethernet/intel/e1000e/hw.h
> @@ -662,6 +662,7 @@ struct e1000_dev_spec_ich8lan {
> bool kmrn_lock_loss_workaround_enabled;
> struct e1000_shadow_ram shadow_ram[E1000_ICH8_SHADOW_RAM_WORDS];
> bool nvm_k1_enabled;
> + bool disable_k1_off;
> bool eee_disable;
I don't see any code actually setting this boolean, how does it work?
^ permalink raw reply
* Re: [PATCH bpf v3] bpf: fix narrower loads on s390
From: Alexei Starovoitov @ 2019-07-23 21:04 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, Network Development, Y Song, gor, Heiko Carstens
In-Reply-To: <20190719091815.92181-1-iii@linux.ibm.com>
On Fri, Jul 19, 2019 at 2:18 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> The very first check in test_pkt_md_access is failing on s390, which
> happens because loading a part of a struct __sk_buff field produces
> an incorrect result.
>
> The preprocessed code of the check is:
>
> {
> __u8 tmp = *((volatile __u8 *)&skb->len +
> ((sizeof(skb->len) - sizeof(__u8)) / sizeof(__u8)));
> if (tmp != ((*(volatile __u32 *)&skb->len) & 0xFF)) return 2;
> };
>
> clang generates the following code for it:
>
> 0: 71 21 00 03 00 00 00 00 r2 = *(u8 *)(r1 + 3)
> 1: 61 31 00 00 00 00 00 00 r3 = *(u32 *)(r1 + 0)
> 2: 57 30 00 00 00 00 00 ff r3 &= 255
> 3: 5d 23 00 1d 00 00 00 00 if r2 != r3 goto +29 <LBB0_10>
>
> Finally, verifier transforms it to:
>
> 0: (61) r2 = *(u32 *)(r1 +104)
> 1: (bc) w2 = w2
> 2: (74) w2 >>= 24
> 3: (bc) w2 = w2
> 4: (54) w2 &= 255
> 5: (bc) w2 = w2
>
> The problem is that when verifier emits the code to replace a partial
> load of a struct __sk_buff field (*(u8 *)(r1 + 3)) with a full load of
> struct sk_buff field (*(u32 *)(r1 + 104)), an optional shift and a
> bitwise AND, it assumes that the machine is little endian and
> incorrectly decides to use a shift.
>
> Adjust shift count calculation to account for endianness.
>
> Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Applied to bpf tree. Thanks
^ permalink raw reply
* Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
From: David Miller @ 2019-07-23 21:06 UTC (permalink / raw)
To: skunberg.kelsey
Cc: iyappan, keyur, quan, netdev, linux-kernel, bjorn, skhan,
linux-kernel-mentees
In-Reply-To: <20190723185811.8548-1-skunberg.kelsey@gmail.com>
From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Date: Tue, 23 Jul 2019 12:58:11 -0600
> acpi_evaluate_object will already return an error if the needed method
> does not exist. Remove unnecessary acpi_has_method() calls and check the
> returned acpi_status for failure instead.
>
> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> ---
> Changes in v2:
> - Fixed white space warnings and errors
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
From: David Miller @ 2019-07-23 21:07 UTC (permalink / raw)
To: skunberg.kelsey
Cc: iyappan, keyur, quan, netdev, linux-kernel, bjorn, skhan,
linux-kernel-mentees
In-Reply-To: <20190723.140646.505566792140054611.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 23 Jul 2019 14:06:46 -0700 (PDT)
> From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> Date: Tue, 23 Jul 2019 12:58:11 -0600
>
>> acpi_evaluate_object will already return an error if the needed method
>> does not exist. Remove unnecessary acpi_has_method() calls and check the
>> returned acpi_status for failure instead.
>>
>> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
>> ---
>> Changes in v2:
>> - Fixed white space warnings and errors
>
> Applied to net-next.
Wow did you even build test this? Reverted...
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function ‘xgene_enet_reset’:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:13: error: invalid storage class for function ‘xgene_enet_cle_bypass’
static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
^~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
^~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:506:13: error: invalid storage class for function ‘xgene_enet_clear’
static void xgene_enet_clear(struct xgene_enet_pdata *pdata,
^~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:522:13: error: invalid storage class for function ‘xgene_enet_shutdown’
static void xgene_enet_shutdown(struct xgene_enet_pdata *p)
^~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:532:13: error: invalid storage class for function ‘xgene_enet_link_state’
static void xgene_enet_link_state(struct work_struct *work)
^~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:563:13: error: invalid storage class for function ‘xgene_sgmac_enable_tx_pause’
static void xgene_sgmac_enable_tx_pause(struct xgene_enet_pdata *p, bool enable)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:604:1: error: expected declaration or statement at end of input
};
^
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:599:29: warning: unused variable ‘xgene_sgport_ops’ [-Wunused-variable]
const struct xgene_port_ops xgene_sgport_ops = {
^~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:582:28: warning: unused variable ‘xgene_sgmac_ops’ [-Wunused-variable]
const struct xgene_mac_ops xgene_sgmac_ops = {
^~~~~~~~~~~~~~~
At top level:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:437:12: warning: ‘xgene_enet_reset’ defined but not used [-Wunused-function]
static int xgene_enet_reset(struct xgene_enet_pdata *p)
^~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH v2 00/10] XDP unaligned chunk placement support
From: Alexei Starovoitov @ 2019-07-23 21:08 UTC (permalink / raw)
To: Kevin Laatz
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Björn Töpel, Karlsson, Magnus, Jakub Kicinski,
Jonathan Lemon, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190716030637.5634-1-kevin.laatz@intel.com>
Johnathan, Bjorn, Jakub,
Please review!
The patch set has been pending for a week.
On Tue, Jul 16, 2019 at 4:21 AM Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> This patch set adds the ability to use unaligned chunks in the XDP umem.
>
> Currently, all chunk addresses passed to the umem are masked to be chunk
> size aligned (default is 2k, max is PAGE_SIZE). This limits where we can
> place chunks within the umem as well as limiting the packet sizes that are
> supported.
>
> The changes in this patch set removes these restrictions, allowing XDP to
> be more flexible in where it can place a chunk within a umem. By relaxing
> where the chunks can be placed, it allows us to use an arbitrary buffer
> size and place that wherever we have a free address in the umem. These
> changes add the ability to support arbitrary frame sizes up to 4k
> (PAGE_SIZE) and make it easy to integrate with other existing frameworks
> that have their own memory management systems, such as DPDK.
>
> Since we are now dealing with arbitrary frame sizes, we need also need to
> update how we pass around addresses. Currently, the addresses can simply be
> masked to 2k to get back to the original address. This becomes less trivial
> when using frame sizes that are not a 'power of 2' size. This patch set
> modifies the Rx/Tx descriptor format to use the upper 16-bits of the addr
> field for an offset value, leaving the lower 48-bits for the address (this
> leaves us with 256 Terabytes, which should be enough!). We only need to use
> the upper 16-bits to store the offset when running in unaligned mode.
> Rather than adding the offset (headroom etc) to the address, we will store
> it in the upper 16-bits of the address field. This way, we can easily add
> the offset to the address where we need it, using some bit manipulation and
> addition, and we can also easily get the original address wherever we need
> it (for example in i40e_zca_free) by simply masking to get the lower
> 48-bits of the address field.
>
> The numbers below were recorded with the following set up:
> - Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
> - Intel Corporation Ethernet Controller XXV710 for 25GbE SFP28 (rev 02)
> - Driver: i40e
> - Application: xdpsock with l2fwd (single interface)
>
> These are solely for comparing performance with and without the patches.
> The largest drop was ~1% (in zero-copy mode).
>
> +-------------------------+------------+-----------------+-------------+
> | Buffer size: 2048 | SKB mode | Zero-copy | Copy |
> +-------------------------+------------+-----------------+-------------+
> | Aligned (baseline) | 1.7 Mpps | 15.3 Mpps | 2.08 Mpps |
> +-------------------------+------------+-----------------+-------------+
> | Aligned (with patches) | 1.7 Mpps | 15.1 Mpps | 2.08 Mpps |
> +-------------------------+------------+-----------------+-------------+
> | Unaligned | 1.7 Mpps | 14.5 Mpps | 2.08 Mpps |
> +-------------------------+------------+-----------------+-------------+
>
> NOTE: We are currently working on the changes required in the Mellanox
> driver. We will include these in the v3.
>
> Structure of the patchset:
> Patch 1:
> - Remove unnecessary masking and headroom addition during zero-copy Rx
> buffer recycling in i40e. This change is required in order for the
> buffer recycling to work in the unaligned chunk mode.
>
> Patch 2:
> - Remove unnecessary masking and headroom addition during
> zero-copy Rx buffer recycling in ixgbe. This change is required in
> order for the buffer recycling to work in the unaligned chunk mode.
>
> Patch 3:
> - Add infrastructure for unaligned chunks. Since we are dealing with
> unaligned chunks that could potentially cross a physical page boundary,
> we add checks to keep track of that information. We can later use this
> information to correctly handle buffers that are placed at an address
> where they cross a page boundary. This patch also modifies the
> existing Rx and Tx functions to use the new descriptor format. To
> handle addresses correctly, we need to mask appropriately based on
> whether we are in aligned or unaligned mode.
>
> Patch 4:
> - This patch updates the i40e driver to make use of the new descriptor
> format. The new format is particularly useful here since we can now
> retrieve the original address in places like i40e_zca_free with ease.
> This saves us doing various calculations to get the original address
> back.
>
> Patch 5:
> - This patch updates the ixgbe driver to make use of the new descriptor
> format. The new format is particularly useful here since we can now
> retrieve the original address in places like ixgbe_zca_free with ease.
> This saves us doing various calculations to get the original address
> back.
>
> Patch 6:
> - Add flags for umem configuration to libbpf
>
> Patch 7:
> - Modify xdpsock application to add a command line option for
> unaligned chunks
>
> Patch 8:
> - Since we can now run the application in unaligned chunk mode, we need
> to make sure we recycle the buffers appropriately.
>
> Patch 9:
> - Adds hugepage support to the xdpsock application
>
> Patch 10:
> - Documentation update to include the unaligned chunk scenario. We need
> to explicitly state that the incoming addresses are only masked in the
> aligned chunk mode and not the unaligned chunk mode.
>
> ---
> v2:
> - fixed checkpatch issues
> - fixed Rx buffer recycling for unaligned chunks in xdpsock
> - removed unused defines
> - fixed how chunk_size is calculated in xsk_diag.c
> - added some performance numbers to cover letter
> - modified descriptor format to make it easier to retrieve original
> address
> - removed patch adding off_t off to the zero copy allocator. This is no
> longer needed with the new descriptor format.
>
> Kevin Laatz (10):
> i40e: simplify Rx buffer recycle
> ixgbe: simplify Rx buffer recycle
> xsk: add support to allow unaligned chunk placement
> i40e: modify driver for handling offsets
> ixgbe: modify driver for handling offsets
> libbpf: add flags to umem config
> samples/bpf: add unaligned chunks mode support to xdpsock
> samples/bpf: add buffer recycling for unaligned chunks to xdpsock
> samples/bpf: use hugepages in xdpsock app
> doc/af_xdp: include unaligned chunk case
>
> Documentation/networking/af_xdp.rst | 10 ++-
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 39 +++++----
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 39 +++++----
> include/net/xdp_sock.h | 2 +
> include/uapi/linux/if_xdp.h | 9 ++
> net/xdp/xdp_umem.c | 17 ++--
> net/xdp/xsk.c | 89 ++++++++++++++++----
> net/xdp/xsk_diag.c | 2 +-
> net/xdp/xsk_queue.h | 70 +++++++++++++--
> samples/bpf/xdpsock_user.c | 61 ++++++++++----
> tools/include/uapi/linux/if_xdp.h | 4 +
> tools/lib/bpf/xsk.c | 3 +
> tools/lib/bpf/xsk.h | 2 +
> 13 files changed, 266 insertions(+), 81 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: added tdc tests for [b|p]fifo qdisc
From: David Miller @ 2019-07-23 21:08 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1563908519-30111-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Tue, 23 Jul 2019 15:01:59 -0400
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Always love to see new tests... Applied.
^ permalink raw reply
* Re: [PATCH v1] net: thunderx: Use fwnode_get_mac_address()
From: David Miller @ 2019-07-23 21:09 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: sgoutham, rric, linux-arm-kernel, netdev
In-Reply-To: <20190723200344.69864-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 23:03:43 +0300
> Replace the custom implementation with fwnode_get_mac_address,
> which works on both DT and ACPI platforms.
>
> While here, replace memcpy() by ether_addr_copy().
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* [PATCH v2 bpf-next] libbpf: provide more helpful message on uninitialized global var
From: Andrii Nakryiko @ 2019-07-23 21:11 UTC (permalink / raw)
To: bpf, netdev, ast, daniel, songliubraving
Cc: andrii.nakryiko, kernel-team, Andrii Nakryiko
When BPF program defines uninitialized global variable, it's put into
a special COMMON section. Libbpf will reject such programs, but will
provide very unhelpful message with garbage-looking section index.
This patch detects special section cases and gives more explicit error
message.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
tools/lib/bpf/libbpf.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 794dd5064ae8..8741c39adb1c 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1760,15 +1760,22 @@ bpf_program__collect_reloc(struct bpf_program *prog, GElf_Shdr *shdr,
(long long) sym.st_value, sym.st_name, name);
shdr_idx = sym.st_shndx;
+ insn_idx = rel.r_offset / sizeof(struct bpf_insn);
+ pr_debug("relocation: insn_idx=%u, shdr_idx=%u\n",
+ insn_idx, shdr_idx);
+
+ if (shdr_idx >= SHN_LORESERVE) {
+ pr_warning("relocation: not yet supported relo for non-static global \'%s\' variable in special section (0x%x) found in insns[%d].code 0x%x\n",
+ name, shdr_idx, insn_idx,
+ insns[insn_idx].code);
+ return -LIBBPF_ERRNO__RELOC;
+ }
if (!bpf_object__relo_in_known_section(obj, shdr_idx)) {
pr_warning("Program '%s' contains unrecognized relo data pointing to section %u\n",
prog->section_name, shdr_idx);
return -LIBBPF_ERRNO__RELOC;
}
- insn_idx = rel.r_offset / sizeof(struct bpf_insn);
- pr_debug("relocation: insn_idx=%u\n", insn_idx);
-
if (insns[insn_idx].code == (BPF_JMP | BPF_CALL)) {
if (insns[insn_idx].src_reg != BPF_PSEUDO_CALL) {
pr_warning("incorrect bpf_call opcode\n");
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf 0/2] bpf: gso_segs fixes
From: Alexei Starovoitov @ 2019-07-23 21:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexei Starovoitov, Daniel Borkmann, David S . Miller, netdev,
Eric Dumazet, Stanislav Fomichev, bpf
In-Reply-To: <20190723101538.136328-1-edumazet@google.com>
On Tue, Jul 23, 2019 at 3:15 AM Eric Dumazet <edumazet@google.com> wrote:
>
> First patch changes the kernel, second patch
> adds a new test.
>
> Note that other patches might be needed to take
> care of similar issues in sock_ops_convert_ctx_access()
> and SOCK_OPS_GET_FIELD()
Nice catch!
Applied to bpf tree. Thanks
^ permalink raw reply
* Re: [net-next 0/6][pull request] 1GbE Intel Wired LAN Driver Updates 2019-07-23
From: Saeed Mahameed @ 2019-07-23 21:16 UTC (permalink / raw)
To: jeffrey.t.kirsher@intel.com, davem@davemloft.net
Cc: nhorman@redhat.com, sassmann@redhat.com, netdev@vger.kernel.org
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
On Tue, 2019-07-23 at 10:36 -0700, Jeff Kirsher wrote:
> This series contains updates to igc and e1000e client drivers only.
>
> Sasha provides a couple of cleanups to remove code that is not needed
> and reduce structure sizes. Updated the MAC reset flow to use the
> device reset flow instead of a port reset flow. Added addition
> device
> id's that will be supported.
>
> Kai-Heng Feng provides a workaround for a possible stalled packet
> issue
> in our ICH devices due to a clock recovery from the PCH being too
> slow.
> Also provided a fix where the MAC & PHY may become de-sync'd causing
> a
> miss detection of link up events.
For what it's worth, Series LGTM.
^ permalink raw reply
* Re: [PATCH v4 net-next 02/19] ionic: Add hardware init and device commands
From: David Miller @ 2019-07-23 21:18 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-3-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:06 -0700
> +void ionic_init_devinfo(struct ionic_dev *idev)
> +{
> + idev->dev_info.asic_type = ioread8(&idev->dev_info_regs->asic_type);
> + idev->dev_info.asic_rev = ioread8(&idev->dev_info_regs->asic_rev);
> +
> + memcpy_fromio(idev->dev_info.fw_version,
> + idev->dev_info_regs->fw_version,
> + IONIC_DEVINFO_FWVERS_BUFLEN);
> +
> + memcpy_fromio(idev->dev_info.serial_num,
> + idev->dev_info_regs->serial_num,
> + IONIC_DEVINFO_SERIAL_BUFLEN);
...
> + sig = ioread32(&idev->dev_info_regs->signature);
I think if you are going to use the io{read,write}{8,16,32,64}()
interfaces then you should use io{read,write}{8,16,32,64}_rep()
instead of memcpy_{to,from}io().
^ permalink raw reply
* Re: [PATCH v4 net-next 05/19] ionic: Add interrupts and doorbells
From: David Miller @ 2019-07-23 21:24 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-6-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:09 -0700
> The ionic interrupt model is based on interrupt control blocks
> accessed through the PCI BAR. Doorbell registers are used by
> the driver to signal to the NIC that requests are waiting on
> the message queues. Interrupts are used by the NIC to signal
> to the driver that answers are waiting on the completion queues.
>
> Signed-off-by: Shannon Nelson <snelson@pensando.io>
After applying this patch we get a warning:
drivers/net/ethernet/pensando/ionic/ionic_lif.c:33:13: warning: ‘ionic_intr_free’ defined but not used [-Wunused-function]
static void ionic_intr_free(struct lif *lif, int index)
^~~~~~~~~~~~~~~
drivers/net/ethernet/pensando/ionic/ionic_lif.c:15:12: warning: ‘ionic_intr_alloc’ defined but not used [-Wunused-function]
static int ionic_intr_alloc(struct lif *lif, struct intr *intr)
^~~~~~~~~~~~~~~~
Also:
> + lif->dbid_inuse = kzalloc(BITS_TO_LONGS(lif->dbid_count) * sizeof(long),
> + GFP_KERNEL);
You can use bitmap_alloc() and friends from linux/bitmap.h for this kind of stuff.
^ permalink raw reply
* Re: [PATCH v4 net-next 06/19] ionic: Add basic adminq support
From: David Miller @ 2019-07-23 21:27 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-7-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:10 -0700
> +struct queue {
...
> +struct cq {
...
> +struct napi_stats {
...
> +struct q_stats {
...
> +struct qcq {
Using names like these and "dev_queue" are just asking for conflicts with the
global datastructure namespace both now and in the future.
Please put ionic_ or similar as a prefix to these data structure names.
Thank you.
^ permalink raw reply
* Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo support
From: David Miller @ 2019-07-23 21:33 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-12-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:15 -0700
> + if (in_interrupt()) {
> + work = kzalloc(sizeof(*work), GFP_ATOMIC);
> + if (!work) {
> + netdev_err(lif->netdev, "%s OOM\n", __func__);
> + return -ENOMEM;
> + }
> + work->type = add ? DW_TYPE_RX_ADDR_ADD : DW_TYPE_RX_ADDR_DEL;
> + memcpy(work->addr, addr, ETH_ALEN);
> + netdev_dbg(lif->netdev, "deferred: rx_filter %s %pM\n",
> + add ? "add" : "del", addr);
> + ionic_lif_deferred_enqueue(&lif->deferred, work);
> + } else {
> + netdev_dbg(lif->netdev, "rx_filter %s %pM\n",
> + add ? "add" : "del", addr);
> + if (add)
> + return ionic_lif_addr_add(lif, addr);
> + else
> + return ionic_lif_addr_del(lif, addr);
> + }
I don't know about this.
Generally interface address changes are expected to be synchronous.
^ permalink raw reply
* Re: [PATCH iproute2] etf: make printing of variable JSON friendly
From: Patel, Vedang @ 2019-07-23 21:34 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
Stephen Hemminger, Gomes, Vinicius, Dorileo, Leandro
In-Reply-To: <0e5fc2fe-dc83-b876-40ac-3b6f3f47bb29@gmail.com>
> On Jul 22, 2019, at 5:11 PM, David Ahern <dsahern@gmail.com> wrote:
>
> On 7/22/19 1:11 PM, Patel, Vedang wrote:
>>
>>
>>> On Jul 22, 2019, at 11:21 AM, David Ahern <dsahern@gmail.com> wrote:
>>>
>>> On 7/19/19 3:40 PM, Vedang Patel wrote:
>>>> In iproute2 txtime-assist series, it was pointed out that print_bool()
>>>> should be used to print binary values. This is to make it JSON friendly.
>>>>
>>>> So, make the corresponding changes in ETF.
>>>>
>>>> Fixes: 8ccd49383cdc ("etf: Add skip_sock_check")
>>>> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
>>>> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
>>>> ---
>>>> tc/q_etf.c | 12 ++++++------
>>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/tc/q_etf.c b/tc/q_etf.c
>>>> index c2090589bc64..307c50eed48b 100644
>>>> --- a/tc/q_etf.c
>>>> +++ b/tc/q_etf.c
>>>> @@ -176,12 +176,12 @@ static int etf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
>>>> get_clock_name(qopt->clockid));
>>>>
>>>> print_uint(PRINT_ANY, "delta", "delta %d ", qopt->delta);
>>>> - print_string(PRINT_ANY, "offload", "offload %s ",
>>>> - (qopt->flags & TC_ETF_OFFLOAD_ON) ? "on" : "off");
>>>> - print_string(PRINT_ANY, "deadline_mode", "deadline_mode %s ",
>>>> - (qopt->flags & TC_ETF_DEADLINE_MODE_ON) ? "on" : "off");
>>>> - print_string(PRINT_ANY, "skip_sock_check", "skip_sock_check %s",
>>>> - (qopt->flags & TC_ETF_SKIP_SOCK_CHECK) ? "on" : "off");
>>>> + if (qopt->flags & TC_ETF_OFFLOAD_ON)
>>>> + print_bool(PRINT_ANY, "offload", "offload ", true);
>>>> + if (qopt->flags & TC_ETF_DEADLINE_MODE_ON)
>>>> + print_bool(PRINT_ANY, "deadline_mode", "deadline_mode ", true);
>>>> + if (qopt->flags & TC_ETF_SKIP_SOCK_CHECK)
>>>> + print_bool(PRINT_ANY, "skip_sock_check", "skip_sock_check", true);
>>>>
>>>> return 0;
>>>> }
>>>>
>>>
>>> This changes existing output for TC_ETF_OFFLOAD_ON and
>>> TC_ETF_DEADLINE_MODE_ON which were added a year ago.
>> Yes, this is a good point. I missed that.
>>
>> Another idea is to use is_json_context() and call print_bool() there. But, that will still change values corresponding to the json output for the above flags from “on”/“off” to “true”/“false”. I am not sure if this is a big issue.
>>
>> My suggestion is to keep the code as is. what do you think?
>>
>
> I think we need automated checkers for new code. ;-)
>
> The first 2 should not change for backward compatibility - unless there
> is agreement that this feature is too new and long term it is better to
> print as above.
>
> Then the new one should follow context of the other 2 - consistency IMHO
> takes precedence.
Thanks for the inputs.
Let’s keep whatever is currently present upstream and you can ignore this patch.
Thanks,
Vedang
^ 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