* [PATCH 1/3] net:svc_rdma_transport: remove unneeded variable 'ret' in rdma_listen_handler
From: zhong jiang @ 2018-08-07 11:20 UTC (permalink / raw)
To: davem, anna.schumaker; +Cc: netdev, linux-kernel
In-Reply-To: <1533640809-1221-1-git-send-email-zhongjiang@huawei.com>
The ret is not modified after initalization, So just remove the variable
and return 0.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/sunrpc/xprtrdma/svc_rdma_transport.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
index 547b2cd..2848caf 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
@@ -296,7 +296,6 @@ static int rdma_listen_handler(struct rdma_cm_id *cma_id,
struct rdma_cm_event *event)
{
struct sockaddr *sap = (struct sockaddr *)&cma_id->route.addr.src_addr;
- int ret = 0;
trace_svcrdma_cm_event(event, sap);
@@ -315,7 +314,7 @@ static int rdma_listen_handler(struct rdma_cm_id *cma_id,
break;
}
- return ret;
+ return 0;
}
static int rdma_cma_handler(struct rdma_cm_id *cma_id,
--
1.7.12.4
^ permalink raw reply related
* [PATCH 3/3] net:mod: remove unneeded variable 'ret' in init_p9
From: zhong jiang @ 2018-08-07 11:20 UTC (permalink / raw)
To: davem, anna.schumaker; +Cc: netdev, linux-kernel
In-Reply-To: <1533640809-1221-1-git-send-email-zhongjiang@huawei.com>
The ret is modified after initalization, so just remove it and
return 0.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/9p/mod.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/9p/mod.c b/net/9p/mod.c
index eb9777f..253ba82 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -171,13 +171,11 @@ void v9fs_put_trans(struct p9_trans_module *m)
*/
static int __init init_p9(void)
{
- int ret = 0;
-
p9_error_init();
pr_info("Installing 9P2000 support\n");
p9_trans_fd_init();
- return ret;
+ return 0;
}
/**
--
1.7.12.4
^ permalink raw reply related
* RE: [RFC PATCH 0/2] net: macb: Disable TX checksum offloading on all Zynq
From: Harini Katakam @ 2018-08-07 9:09 UTC (permalink / raw)
To: Claudiu Beznea, Jennifer Dahm
Cc: netdev@vger.kernel.org, David S . Miller, Nathan Sullivan,
Rafal Ozieblo, Nicolas Ferre,
'harinikatakamlinux@gmail.com'
In-Reply-To: <2fa65708-31f4-9236-3ed5-f2f87cdfe3b7@microchip.com>
Hi Claudiu,
> -----Original Message-----
> From: Claudiu Beznea [mailto:Claudiu.Beznea@microchip.com]
> Sent: Tuesday, August 7, 2018 2:21 PM
> To: Harini Katakam <harinik@xilinx.com>; Jennifer Dahm
> <jennifer.dahm@ni.com>
> Cc: netdev@vger.kernel.org; David S . Miller <davem@davemloft.net>; Nathan
> Sullivan <nathan.sullivan@ni.com>; Rafal Ozieblo <rafalo@cadence.com>;
> Harini Katakam <harinik@xilinx.com>; Nicolas Ferre
> <nicolas.ferre@microchip.com>
> Subject: Re: [RFC PATCH 0/2] net: macb: Disable TX checksum offloading on all
> Zynq
>
> Hi Harini,
>
> On 01.08.2018 15:53, Harini Katakam wrote:
> > Hi Jennifer,
> >
> > On Tue, Jun 5, 2018 at 10:21 AM, Harini Katakam <harinik@xilinx.com> wrote:
> >> Hi Jeniffer,
> >>
> >> On Mon, Jun 4, 2018 at 8:35 PM, Nicolas Ferre
> >> <nicolas.ferre@microchip.com> wrote:
> >>> Jennifer,
> >>>
> >>> On 25/05/2018 at 23:44, Jennifer Dahm wrote:
> >>>>
> >>>> During testing, I discovered that the Zynq GEM hardware overwrites
> >>>> all outgoing UDP packet checksums, which is illegal in packet
> >>>> forwarding cases. This happens both with and without the
> >>>> checksum-zeroing behavior introduced in
> >>>> 007e4ba3ee137f4700f39aa6dbaf01a71047c5f6
> >>>> ("net: macb: initialize checksum when using checksum offloading").
> >>>> The only solution to both the small packet bug and the packet
> >>>> forwarding bug that I can find is to disable TX checksum offloading
> entirely.
> >>>
> >>>
> >>
> >> Thanks for the extensive testing.
> >> I'll try to reproduce and see if it is something to be fixed in the driver.
> >>
> >>> Are the bugs listed above present in all revisions of the GEM IP,
> >>> only for some revisions?
> >>> Is there an errata that describe this issue for the Zynq GEM?
> >>
> >> @Nicolas, AFAIK, there is no errata for this in either Cadence or
> >> Zynq documentation.
> >
> > I was unable to reproduce this issue on Zynq.
> > Although I do not have HW with two GEM ports, I tried by routing one
> > GEM via PL and another via on board RGMII.
> > Since there was no specific errata related to this, I also tried on
> > subsequent ZynqMP versions with multiple GEM ports but dint find any
> > checksum issues. I discussed the same with cadence and they tried the
> > test with 2 bytes of UDP payload on the Zynq GEM IP version in their
> > regressions and did not hit any issue either.
> >
> > I tried to reach out earlier to see if you can share your exact
> > application. Could you please let me know if you have any further
> > updates?
>
> I manage to reproduce the issue and provide a patch for this (see patch 3/3 from
> [1]).
>
> [1] https://www.spinics.net/lists/netdev/msg513848.html
Sorry, I missed your series. Thanks.
Regards,
Harini
^ permalink raw reply
* [PATCH net-next] RDS: IB: fix 'passing zero to ERR_PTR()' warning
From: YueHaibing @ 2018-08-07 11:34 UTC (permalink / raw)
To: santosh.shilimkar, davem
Cc: linux-kernel, netdev, linux-rdma, rds-devel, YueHaibing
Fix a static code checker warning:
net/rds/ib_frmr.c:82 rds_ib_alloc_frmr() warn: passing zero to 'ERR_PTR'
The error path for ib_alloc_mr failure should set err to PTR_ERR.
Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/rds/ib_frmr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/rds/ib_frmr.c b/net/rds/ib_frmr.c
index b371cf0..6431a02 100644
--- a/net/rds/ib_frmr.c
+++ b/net/rds/ib_frmr.c
@@ -61,6 +61,7 @@ static struct rds_ib_mr *rds_ib_alloc_frmr(struct rds_ib_device *rds_ibdev,
pool->fmr_attr.max_pages);
if (IS_ERR(frmr->mr)) {
pr_warn("RDS/IB: %s failed to allocate MR", __func__);
+ err = PTR_ERR(frmr->mr);
goto out_no_cigar;
}
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] Use Kconfig flag to remove support of deprecated BE2/BE3 adapters
From: Ivan Vecera @ 2018-08-07 11:35 UTC (permalink / raw)
To: Christoph Hellwig, Petr Oros
Cc: netdev, Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna,
Somnath Kotur, David S. Miller, linux-kernel
In-Reply-To: <20180806162153.GA22040@infradead.org>
On 6.8.2018 18:21, Christoph Hellwig wrote:
> On Mon, Aug 06, 2018 at 02:12:28PM +0200, Petr Oros wrote:
>> Add flags to remove support of deprecated BE2/BE3 adapters.
>> BE2 disable will reduce .ko size by 2kb and BE3 by 3kb.
>> Disable both will reduce .ko size by 9kb.
>>
>> With dissabled support is also removed coresponding PCI IDs
>> and codepath with [BE2|BE3|BEx]_chip checks.
>
> deprecated seems like a really odd world for hardware.
>
> Are they just old? Did they never ship in large numbers?
>
> If you just make some cards optional why not also add options
> for families of newer cards for those who only have the older ones
> in their systems?
>
This also makes sense.
I.
^ permalink raw reply
* [PATCH 2/3] net: macb: move checksum clearing outside of spinlock
From: Claudiu Beznea @ 2018-08-07 9:25 UTC (permalink / raw)
To: nicolas.ferre, davem
Cc: netdev, linux-kernel, harinik, jennifer.dahm, nathan.sullivan,
rafalo, harinikatakamlinux, Claudiu Beznea
In-Reply-To: <1533633914-30264-1-git-send-email-claudiu.beznea@microchip.com>
Move checksum clearing outside of spinlock. The SKB is protected by
networking lock (HARD_TX_LOCK()).
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
drivers/net/ethernet/cadence/macb_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 860436474c3e..1c12afe4a0ce 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1662,6 +1662,11 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
bool is_lso, is_udp = 0;
netdev_tx_t ret = NETDEV_TX_OK;
+ if (macb_clear_csum(skb)) {
+ dev_kfree_skb_any(skb);
+ return ret;
+ }
+
is_lso = (skb_shinfo(skb)->gso_size != 0);
if (is_lso) {
@@ -1717,11 +1722,6 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_BUSY;
}
- if (macb_clear_csum(skb)) {
- dev_kfree_skb_any(skb);
- goto unlock;
- }
-
/* Map socket buffer for DMA transfer */
if (!macb_tx_map(bp, queue, skb, hdrlen)) {
dev_kfree_skb_any(skb);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] Use Kconfig flag to remove support of deprecated BE2/BE3 adapters
From: Ivan Vecera @ 2018-08-07 11:44 UTC (permalink / raw)
To: David Miller, poros
Cc: netdev, sathya.perla, ajit.khaparde, sriharsha.basavapatna,
somnath.kotur, linux-kernel
In-Reply-To: <20180806.134620.124956510948789350.davem@davemloft.net>
On 6.8.2018 22:46, David Miller wrote:
> From: Petr Oros <poros@redhat.com>
> Date: Mon, 6 Aug 2018 14:12:28 +0200
>
>> Add flags to remove support of deprecated BE2/BE3 adapters.
>> BE2 disable will reduce .ko size by 2kb and BE3 by 3kb.
>> Disable both will reduce .ko size by 9kb.
>>
>> With dissabled support is also removed coresponding PCI IDs
>> and codepath with [BE2|BE3|BEx]_chip checks.
>>
>> New help style in Kconfig
>>
>> Signed-off-by: Petr Oros <poros@redhat.com>
>
> Sorry, I'm not too hot about this.
Why? This patch does not remove support for older chips, it just gives an
ability to disable support for certain chip families. In other words an user is
able to customize the driver for his/her needs - it could be fine to add this
ability also for the rest of chip families.
> Imagine being one of the people who has one of these cards.
Such people leave this configs as they are (enabled by default).
> Pulling out detection and working'ness of devices from a driver
> is a big step backwards, and I'm sorry I will don't want to be
> part of something that facilitates this.
>
> The S390 folks tried something similar in the past and I reject
> those changes too.
This patch is practically the same as "a1b8714593b6 ("net/mlx4: Use Kconfig flag
to remove support of old gen2 Mellanox devices")" for mlx4 and that was accepted
without any objections.
Thanks,
Ivan
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: introduce update_effective_progs()
From: Daniel Borkmann @ 2018-08-07 12:31 UTC (permalink / raw)
To: Roman Gushchin, netdev; +Cc: linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <20180806212728.8514-1-guro@fb.com>
On 08/06/2018 11:27 PM, Roman Gushchin wrote:
> __cgroup_bpf_attach() and __cgroup_bpf_detach() functions have
> a good amount of duplicated code, which is possible to eliminate
> by introducing the update_effective_progs() helper function.
>
> The update_effective_progs() calls compute_effective_progs()
> and then in case of success it calls activate_effective_progs()
> for each descendant cgroup. In case of failure (OOM), it releases
> allocated prog arrays and return the error code.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Song Liu <songliubraving@fb.com>
Applied to bpf-next, thanks Roman!
^ permalink raw reply
* [PATCH net-next] ceph: remove unnecessary non NULL check for request_key
From: YueHaibing @ 2018-08-07 13:02 UTC (permalink / raw)
To: davem, idryomov, zyan, sage; +Cc: linux-kernel, netdev, ceph-devel, YueHaibing
request_key never return NULL,so no need do non-NULL check.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/ceph/ceph_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ceph/ceph_common.c b/net/ceph/ceph_common.c
index 584fdbe..9834edc 100644
--- a/net/ceph/ceph_common.c
+++ b/net/ceph/ceph_common.c
@@ -304,7 +304,7 @@ static int get_secret(struct ceph_crypto_key *dst, const char *name) {
struct ceph_crypto_key *ckey;
ukey = request_key(&key_type_ceph, name, NULL);
- if (!ukey || IS_ERR(ukey)) {
+ if (IS_ERR(ukey)) {
/* request_key errors don't map nicely to mount(2)
errors; don't even try, but still printk */
key_err = PTR_ERR(ukey);
--
2.7.0
^ permalink raw reply related
* Re: [RFC bpf-next v2 3/3] docs: Split filter.txt into separate documents.
From: Jonathan Corbet @ 2018-08-07 13:14 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Daniel Borkmann, Alexei Starovoitov, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180807024844.GW3088@eros>
On Tue, 7 Aug 2018 12:48:44 +1000
"Tobin C. Harding" <me@tobin.cc> wrote:
> How about these steps:
>
> 1. start with foo.txt
> 2. do typo and grammar fixes (any number of patches).
> 3. rename to foo.rst, do whitespace changes, code snippet
> indentation, heading adornments, update references to this file.
> (single patch).
> 4. Fix up references in the file text to use RST (i.e :ref: blah)
> 5. Fix up RST markers (backticks etc). (any number of patches)
That can certainly work; just don't call it foo.rst until it actually is a
valid RST file.
And, of course, go easy with the later steps and try to avoid the
temptation to mark up everything; we really want to preserve the
readability of the plain-text files.
Thanks for doing this work!
jon
^ permalink raw reply
* AW: AW: AW: PROBLEM: Kernel Oops in UDP stack
From: Marcel Hellwig @ 2018-08-07 13:42 UTC (permalink / raw)
To: 'Eric Dumazet', 'David Laight',
'davem@davemloft.net', 'kuznet@ms2.inr.ac.ru',
'yoshfuji@linux-ipv6.org', 'andrew@lunn.ch'
Cc: 'netdev@vger.kernel.org',
'linux-kernel@vger.kernel.org', Matthias Wystrik
In-Reply-To: <936fbc1f39424adea318bcd95f50d63d@ZCOM03.mut-group.com>
>>
>> Well, this driver does not use NET_IP_ALIGN reservation, meaning IP header is not 4-byte aligned.
>>
>> No idea why mis-alignments are okay in IP layer, but not in UDP
>>
>> You could try to patch it to use netdev_alloc_skb_ip_align() instead of dev_alloc_skb()
>
> Looks very promising! CPU runs for 3 hours and no panic so far. Let's hope it survives the weekend! *fingers crossed* The strange thing I don't understand is, why does the 3.5.7 kernel does not crash (or 4.17.12, yes I managed to run a recent kernel on our machine! \o/ )? It does not use netdev_alloc_skb_ip_align either[0][1], but one thing, that I noticed it, that there is a difference in /proc/iomem
>
> 3.4.113
> # cat /proc/iomem
> 08000000-0801ffff : lpc-eth.0
> 31060000-31060fff : lpc-eth.0
> 40088000-4008801f : serial
> [...]
>
> 3.5.7
> # cat /proc/iomem
> 20084000-20084fff : /ahb/apb/ssp@20084000
> 2008c000-2008cfff : /ahb/apb/ssp@2008c000
> 31000000-31000fff : /ahb/dma@31000000
> 40088000-4008801f : serial
> [...]
>
> As you notice lpc-eth.0 (or 31060000.ethernet as it's called nowadays) is not listed, so my guess it is served by DMA?
>
> May that the reason why it does not crash (Notice: 3.5.7 runs via device tree file)?
>
> So just my thought: If I would disable dma (somehow) would the error still occur in today's kernel?
I think, that it is implicitly aligned today (I think!), so that's the reason why the oops does not occur anymore.
Our machines survived the 4 days now, so we are very confident, that this solved the problem for us!
Thank you very much, you all helped us a lot!
Mit freundlichen Grüßen / With kind regards
Marcel Hellwig
B. Sc. Informatik
Entwickler
m-u-t GmbH
Am Marienhof 2
22880 Wedel
Germany
Phone: +49 4103 9308 - 474
Fax: +49 4103 9308 - 99
mhellwig@mut-group.com
www.mut-group.com
Geschäftsführer (Managing Director): Fabian Peters Amtsgericht Pinneberg (Commercial Register No.): HRB 10304 PI USt-IdNr. (VAT-No.): DE228275390
WEEE-Reg-Nr.: DE 72271808
^ permalink raw reply
* [PATCH 2/3] net:af_iucv: get rid of the unneeded variable 'err' in afiucv_pm_freeze
From: zhong jiang @ 2018-08-07 11:20 UTC (permalink / raw)
To: davem, anna.schumaker; +Cc: netdev, linux-kernel
In-Reply-To: <1533640809-1221-1-git-send-email-zhongjiang@huawei.com>
We will not use the variable 'err' after initalization, So remove it and
return 0.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/iucv/af_iucv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 92ee91e..a21d8ed 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -150,7 +150,6 @@ static int afiucv_pm_freeze(struct device *dev)
{
struct iucv_sock *iucv;
struct sock *sk;
- int err = 0;
#ifdef CONFIG_PM_DEBUG
printk(KERN_WARNING "afiucv_pm_freeze\n");
@@ -175,7 +174,7 @@ static int afiucv_pm_freeze(struct device *dev)
skb_queue_purge(&iucv->backlog_skb_q);
}
read_unlock(&iucv_sk_list.lock);
- return err;
+ return 0;
}
/**
--
1.7.12.4
^ permalink raw reply related
* RE: [PATCH net-next] [RFC] dpaa2-eth: Move DPAA2 Ethernet driver from staging to drivers/net
From: Ioana Ciocoi Radulescu @ 2018-08-07 13:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: devel@driverdev.osuosl.org, Horia Geanta,
gregkh@linuxfoundation.org, netdev@vger.kernel.org,
Madalin-cristian Bucur, linux-kernel@vger.kernel.org,
Ioana Ciornei, davem@davemloft.net, Laurentiu Tudor
In-Reply-To: <20180803164239.GG15029@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, August 3, 2018 7:43 PM
> To: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
> Cc: netdev@vger.kernel.org; davem@davemloft.net;
> gregkh@linuxfoundation.org; devel@driverdev.osuosl.org; linux-
> kernel@vger.kernel.org; Ioana Ciornei <ioana.ciornei@nxp.com>; Laurentiu
> Tudor <laurentiu.tudor@nxp.com>; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Horia Geanta <horia.geanta@nxp.com>
> Subject: Re: [PATCH net-next] [RFC] dpaa2-eth: Move DPAA2 Ethernet driver
> from staging to drivers/net
>
> > +static int dpaa2_eth_probe(struct fsl_mc_device *dpni_dev)
> > +{
> > + struct device *dev;
> > + struct net_device *net_dev = NULL;
> > + struct dpaa2_eth_priv *priv = NULL;
> > + int err = 0;
> > +
> > + dev = &dpni_dev->dev;
> > +
> > + /* Net device */
> > + net_dev = alloc_etherdev_mq(sizeof(*priv),
> DPAA2_ETH_MAX_TX_QUEUES);
> > + if (!net_dev) {
> > + dev_err(dev, "alloc_etherdev_mq() failed\n");
> > + return -ENOMEM;
> > + }
> > +
> > + SET_NETDEV_DEV(net_dev, dev);
> > + dev_set_drvdata(dev, net_dev);
> > +
> > + priv = netdev_priv(net_dev);
> > + priv->net_dev = net_dev;
> > +
> > + priv->iommu_domain = iommu_get_domain_for_dev(dev);
> > +
> > + /* Obtain a MC portal */
> > + err = fsl_mc_portal_allocate(dpni_dev,
> FSL_MC_IO_ATOMIC_CONTEXT_PORTAL,
> > + &priv->mc_io);
> > + if (err) {
> > + if (err == -ENXIO)
> > + err = -EPROBE_DEFER;
> > + else
> > + dev_err(dev, "MC portal allocation failed\n");
> > + goto err_portal_alloc;
> > + }
> > +
> > + /* MC objects initialization and configuration */
> > + err = setup_dpni(dpni_dev);
> > + if (err)
> > + goto err_dpni_setup;
> > +
> > + err = setup_dpio(priv);
> > + if (err)
> > + goto err_dpio_setup;
> > +
> > + setup_fqs(priv);
> > +
> > + err = setup_dpbp(priv);
> > + if (err)
> > + goto err_dpbp_setup;
> > +
> > + err = bind_dpni(priv);
> > + if (err)
> > + goto err_bind;
> > +
> > + /* Add a NAPI context for each channel */
> > + add_ch_napi(priv);
> > +
> > + /* Percpu statistics */
> > + priv->percpu_stats = alloc_percpu(*priv->percpu_stats);
> > + if (!priv->percpu_stats) {
> > + dev_err(dev, "alloc_percpu(percpu_stats) failed\n");
> > + err = -ENOMEM;
> > + goto err_alloc_percpu_stats;
> > + }
> > + priv->percpu_extras = alloc_percpu(*priv->percpu_extras);
> > + if (!priv->percpu_extras) {
> > + dev_err(dev, "alloc_percpu(percpu_extras) failed\n");
> > + err = -ENOMEM;
> > + goto err_alloc_percpu_extras;
> > + }
> > +
> > + err = netdev_init(net_dev);
> > + if (err)
> > + goto err_netdev_init;
>
> At the end of netdev_init() you call netdev_register(). From that
> point on, you device is live. Its .ndo's can be called....
>
> > +
> > + /* Configure checksum offload based on current interface flags */
> > + err = set_rx_csum(priv, !!(net_dev->features & NETIF_F_RXCSUM));
> > + if (err)
> > + goto err_csum;
> > +
> > + err = set_tx_csum(priv, !!(net_dev->features &
> > + (NETIF_F_IP_CSUM |
> NETIF_F_IPV6_CSUM)));
> > + if (err)
> > + goto err_csum;
> > +
> > + err = alloc_rings(priv);
> > + if (err)
> > + goto err_alloc_rings;
>
> How well does the device work if it has not allocated the rings yet,
> when it is asked to do something?
>
> > +
> > + net_dev->ethtool_ops = &dpaa2_ethtool_ops;
> > +
> > + err = setup_irqs(dpni_dev);
>
> How well do it work without interrupts being set up?
>
> > + if (err) {
> > + netdev_warn(net_dev, "Failed to set link interrupt, fall back
> to polling\n");
> > + priv->poll_thread = kthread_run(poll_link_state, priv,
> > + "%s_poll_link", net_dev-
> >name);
> > + if (IS_ERR(priv->poll_thread)) {
> > + netdev_err(net_dev, "Error starting polling
> thread\n");
> > + goto err_poll_thread;
> > + }
> > + priv->do_link_poll = true;
> > + }
>
> Probably the correct place to register the netdev is here.
Good point, I'll fix it in v2.
Thanks a lot,
Ioana
^ permalink raw reply
* Re: [PATCH v4] can: sja1000: plx_pci: add support for ASEM CAN raw device
From: Marc Kleine-Budde @ 2018-08-07 14:11 UTC (permalink / raw)
To: Flavio Suligoi, Wolfgang Grandegger
Cc: David S . Miller, linux-can, netdev, linux-kernel
In-Reply-To: <1533626239-4065-1-git-send-email-f.suligoi@asem.it>
[-- Attachment #1.1: Type: text/plain, Size: 5641 bytes --]
On 08/07/2018 09:17 AM, Flavio Suligoi wrote:
> This patch adds support for ASEM opto-isolated dual channels
> CAN raw device (http://www.asem.it)
>
> Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
> ---
>
> v2: - rename ASEM_... constants to reduce space size;
> - remove "else" in "plx_pci_reset_asem_dual_can_raw" function to avoid
> strings breaking
> v3: - fix wrong comment for PLX_LINT2_POL
> - put string into just one line in "plx_pci_reset_asem_dual_can_raw"
> function
> v4: - remove unnecessary variable "reset_bar" in
> "plx_pci_reset_asem_dual_can_raw" function
>
> drivers/net/can/sja1000/Kconfig | 1 +
> drivers/net/can/sja1000/plx_pci.c | 66 ++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
> index 1e65cb6..f6dc899 100644
> --- a/drivers/net/can/sja1000/Kconfig
> +++ b/drivers/net/can/sja1000/Kconfig
> @@ -88,6 +88,7 @@ config CAN_PLX_PCI
> - TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/)
> - IXXAT Automation PC-I 04/PCI card (http://www.ixxat.com/)
> - Connect Tech Inc. CANpro/104-Plus Opto (CRG001) card (http://www.connecttech.com)
> + - ASEM CAN raw - 2 isolated CAN channels (www.asem.it)
>
> config CAN_TSCAN1
> tristate "TS-CAN1 PC104 boards"
> diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
> index f8ff25c..79fc327 100644
> --- a/drivers/net/can/sja1000/plx_pci.c
> +++ b/drivers/net/can/sja1000/plx_pci.c
> @@ -46,7 +46,8 @@ MODULE_SUPPORTED_DEVICE("Adlink PCI-7841/cPCI-7841, "
> "esd CAN-PCIe/2000, "
> "Connect Tech Inc. CANpro/104-Plus Opto (CRG001), "
> "IXXAT PC-I 04/PCI, "
> - "ELCUS CAN-200-PCI")
> + "ELCUS CAN-200-PCI, "
> + "ASEM DUAL CAN-RAW")
> MODULE_LICENSE("GPL v2");
>
> #define PLX_PCI_MAX_CHAN 2
> @@ -70,7 +71,9 @@ struct plx_pci_card {
> */
>
> #define PLX_LINT1_EN 0x1 /* Local interrupt 1 enable */
> +#define PLX_LINT1_POL (1 << 1) /* Local interrupt 1 polarity */
> #define PLX_LINT2_EN (1 << 3) /* Local interrupt 2 enable */
> +#define PLX_LINT2_POL (1 << 4) /* Local interrupt 2 polarity */
> #define PLX_PCI_INT_EN (1 << 6) /* PCI Interrupt Enable */
> #define PLX_PCI_RESET (1 << 30) /* PCI Adapter Software Reset */
>
> @@ -92,6 +95,9 @@ struct plx_pci_card {
> */
> #define PLX_PCI_OCR (OCR_TX0_PUSHPULL | OCR_TX1_PUSHPULL)
>
> +/* OCR setting for ASEM Dual CAN raw */
> +#define ASEM_PCI_OCR 0xfe
> +
> /*
> * In the CDR register, you should set CBP to 1.
> * You will probably also want to set the clock divider value to 7
> @@ -145,10 +151,20 @@ struct plx_pci_card {
> #define MOXA_PCI_VENDOR_ID 0x1393
> #define MOXA_PCI_DEVICE_ID 0x0100
>
> +#define ASEM_RAW_CAN_VENDOR_ID 0x10b5
> +#define ASEM_RAW_CAN_DEVICE_ID 0x9030
> +#define ASEM_RAW_CAN_SUB_VENDOR_ID 0x3000
> +#define ASEM_RAW_CAN_SUB_DEVICE_ID 0x1001
> +#define ASEM_RAW_CAN_SUB_DEVICE_ID_BIS 0x1002
> +#define ASEM_RAW_CAN_RST_REGISTER 0x54
> +#define ASEM_RAW_CAN_RST_MASK_CAN1 0x20
> +#define ASEM_RAW_CAN_RST_MASK_CAN2 0x04
> +
> static void plx_pci_reset_common(struct pci_dev *pdev);
> static void plx9056_pci_reset_common(struct pci_dev *pdev);
> static void plx_pci_reset_marathon_pci(struct pci_dev *pdev);
> static void plx_pci_reset_marathon_pcie(struct pci_dev *pdev);
> +static void plx_pci_reset_asem_dual_can_raw(struct pci_dev *pdev);
>
> struct plx_pci_channel_map {
> u32 bar;
> @@ -269,6 +285,14 @@ static struct plx_pci_card_info plx_pci_card_info_moxa = {
> /* based on PLX9052 */
> };
>
> +static struct plx_pci_card_info plx_pci_card_info_asem_dual_can = {
> + "ASEM Dual CAN raw PCI", 2,
> + PLX_PCI_CAN_CLOCK, ASEM_PCI_OCR, PLX_PCI_CDR,
> + {0, 0x00, 0x00}, { {2, 0x00, 0x00}, {4, 0x00, 0x00} },
> + &plx_pci_reset_asem_dual_can_raw
> + /* based on PLX9030 */
> +};
> +
> static const struct pci_device_id plx_pci_tbl[] = {
> {
> /* Adlink PCI-7841/cPCI-7841 */
> @@ -375,6 +399,20 @@ static const struct pci_device_id plx_pci_tbl[] = {
> 0, 0,
> (kernel_ulong_t)&plx_pci_card_info_moxa
> },
> + {
> + /* ASEM Dual CAN raw */
> + ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> + ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID,
> + 0, 0,
> + (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
> + },
> + {
> + /* ASEM Dual CAN raw -new model */
> + ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> + ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID_BIS,
> + 0, 0,
> + (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
> + },
> { 0,}
> };
> MODULE_DEVICE_TABLE(pci, plx_pci_tbl);
> @@ -524,6 +562,32 @@ static void plx_pci_reset_marathon_pcie(struct pci_dev *pdev)
> }
> }
>
> +/* Special reset function for ASEM Dual CAN raw card */
> +static void plx_pci_reset_asem_dual_can_raw(struct pci_dev *pdev)
> +{
> + void __iomem *bar0_addr;
> + u8 tmpval;
> +
> + plx_pci_reset_common(pdev);
> +
> + bar0_addr = pci_iomap(pdev, 0, 0);
> + if (!bar0_addr) {
> + dev_err(&pdev->dev, "Failed to remap reset space %d (BAR%d)\n",
> + 0, 0);
I've put both 0 directly into the string while applying the patch.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] rtlwifi: btcoex: Fix if == else warnings in halbtc8723b2ant.c
From: Larry Finger @ 2018-08-07 14:23 UTC (permalink / raw)
To: valdis.kletnieks, YueHaibing
Cc: pkshih, kvalo, linux-kernel, netdev, davem, colin.king,
linux-wireless
In-Reply-To: <63216.1533591775@turing-police.cc.vt.edu>
On 08/06/2018 04:42 PM, valdis.kletnieks@vt.edu wrote:
> On Mon, 06 Aug 2018 12:54:40 +0800, YueHaibing said:
>> Fix following coccinelle warning:
>>
>> ./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2952:2-4: WARNING: possible condition with no effect (if == else)
>
>> /* sw mechanism */
>> if (BTC_WIFI_BW_HT40 == wifi_bw) {
>> - if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
>> - (wifi_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
>> - btc8723b2ant_sw_mechanism(btcoexist, true, true,
>> - false, false);
>> - } else {
>> - btc8723b2ant_sw_mechanism(btcoexist, true, true,
>> - false, false);
>> - }
>> + btc8723b2ant_sw_mechanism(btcoexist, true, true,
>> + false, false);
>> } else {
>
> Rather than blindly fixing this, perhaps a bit of thought needs to be
> applied to why this code looks like this in the first place.
>
> See commit c6821613e653a (which looks like the bletcherous "do too many
> things at once" commit indeed), although the actual diff appears to be a
> "no harm, no foul" against this commit, where the issue already existed.
>
> commit aa45a673b291fd761275493bc15316d79555ed55
> Author: Larry Finger <Larry.Finger@lwfinger.net>
> Date: Fri Feb 28 15:16:43 2014 -0600
>
> rtlwifi: btcoexist: Add new mini driver
>
> Larry? Can you reach back to 2014 and remember why this code
> looked like this in the first place?
The base code came from Realtek. My only part in getting it into the kernel was
to clean up the checkpatch and Sparse errors and warnings, and submit it. I was
a "script kiddy" just like the authors of the current patches. The only
difference is that I was getting drivers into the kernel so that users hardware
would work.
Any record of whether these duplicate branches are the result of incorrect copy
and paste, or just extraneous code, would be at Realtek in their version control
history. I have never had access to such archives, nor have I ever had an
non-disclosure agreement with Realtek.
Ping-Ke Shih, who is Cc'd on these messages, might be able to answer these
questions.
For the moment, these simplifications could be applied as long as they are
correctly done. After all, they are not changing what is already there and that
stops any other person that knows how to run coccinelle from submitting the same
patch in the future. Why "kick the can down the road"? If PK can find that there
was an error in the original code, he can submit a "Fixes" patch.
Larry
^ permalink raw reply
* WARNING: refcount bug in llc_sap_find
From: syzbot @ 2018-08-07 14:59 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 0585df468e8f Merge tag 'media/v4.18-3' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15927272400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f
dashboard link: https://syzkaller.appspot.com/bug?extid=278893f3f7803871f7ce
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1064ef78400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17d0fa8c400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+278893f3f7803871f7ce@syzkaller.appspotmail.com
------------[ cut here ]------------
refcount_t: increment on 0; use-after-free.
WARNING: CPU: 0 PID: 25217 at lib/refcount.c:153 refcount_inc+0x5d/0x70
lib/refcount.c:153
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 25217 Comm: syz-executor271 Not tainted 4.18.0-rc7+ #175
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:refcount_inc+0x5d/0x70 lib/refcount.c:153
Code: 1d 9c ef 25 05 31 ff 89 de e8 6f b0 1c fe 84 db 75 df e8 96 af 1c fe
48 c7 c7 40 4b 3a 87 c6 05 7c ef 25 05 01 e8 93 c8 e7 fd <0f> 0b eb c3 0f
1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89
RSP: 0018:ffff8801d6cd7af8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff81632481 RDI: ffff8801d6cd77d0
RBP: ffff8801d6cd7b00 R08: ffff8801bfbf65c0 R09: 0000000000000002
R10: ffff8801bfbf65c0 R11: 0000000000000000 R12: 00000000000000ff
R13: dffffc0000000000 R14: 00000000000000ff R15: ffff8801d6cd7d17
llc_sap_hold include/net/llc.h:116 [inline]
llc_sap_find+0x1ec/0x2a0 net/llc/llc_core.c:77
llc_ui_bind+0x6c7/0xf10 net/llc/af_llc.c:362
__sys_bind+0x331/0x440 net/socket.c:1493
__do_sys_bind net/socket.c:1504 [inline]
__se_sys_bind net/socket.c:1502 [inline]
__x64_sys_bind+0x73/0xb0 net/socket.c:1502
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445ca9
Code: e8 ac e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff435ebcdb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000445ca9
RDX: 0000000000000010 RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac2c
R13: 00007ffe0636e23f R14: 00007ff435ebd9c0 R15: 00000000006dac20
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net-next] ceph: remove unnecessary non NULL check for request_key
From: Ilya Dryomov @ 2018-08-07 15:02 UTC (permalink / raw)
To: yuehaibing
Cc: David S. Miller, Yan, Zheng, Sage Weil, linux-kernel, netdev,
Ceph Development
In-Reply-To: <20180807130234.5380-1-yuehaibing@huawei.com>
On Tue, Aug 7, 2018 at 3:03 PM YueHaibing <yuehaibing@huawei.com> wrote:
>
> request_key never return NULL,so no need do non-NULL check.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> net/ceph/ceph_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ceph/ceph_common.c b/net/ceph/ceph_common.c
> index 584fdbe..9834edc 100644
> --- a/net/ceph/ceph_common.c
> +++ b/net/ceph/ceph_common.c
> @@ -304,7 +304,7 @@ static int get_secret(struct ceph_crypto_key *dst, const char *name) {
> struct ceph_crypto_key *ckey;
>
> ukey = request_key(&key_type_ceph, name, NULL);
> - if (!ukey || IS_ERR(ukey)) {
> + if (IS_ERR(ukey)) {
> /* request_key errors don't map nicely to mount(2)
> errors; don't even try, but still printk */
> key_err = PTR_ERR(ukey);
Applied.
Thanks,
Ilya
^ permalink raw reply
* [PATCH net-next v3 1/3] qed: Add DCBX API - qed_dcbx_get_priority_tc()
From: Denis Bolotin @ 2018-08-07 12:48 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin, Michal Kalderon, Ariel Elior
In-Reply-To: <20180807124810.17386-1-denis.bolotin@cavium.com>
The API receives a priority and looks for the TC it is mapped to in the
operational DCBX configuration. The API returns QED_DCBX_DEFAULT_TC (0)
when DCBX is disabled.
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 18 ++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index d02e774..86307b9 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -989,6 +989,24 @@ void qed_dcbx_set_pf_update_params(struct qed_dcbx_results *p_src,
qed_dcbx_update_protocol_data(p_dcb_data, p_src, DCBX_PROTOCOL_ETH);
}
+u8 qed_dcbx_get_priority_tc(struct qed_hwfn *p_hwfn, u8 pri)
+{
+ struct qed_dcbx_get *dcbx_info = &p_hwfn->p_dcbx_info->get;
+
+ if (pri >= QED_MAX_PFC_PRIORITIES) {
+ DP_ERR(p_hwfn, "Invalid priority %d\n", pri);
+ return QED_DCBX_DEFAULT_TC;
+ }
+
+ if (!dcbx_info->operational.valid) {
+ DP_VERBOSE(p_hwfn, QED_MSG_DCB,
+ "Dcbx parameters not available\n");
+ return QED_DCBX_DEFAULT_TC;
+ }
+
+ return dcbx_info->operational.params.ets_pri_tc_tbl[pri];
+}
+
#ifdef CONFIG_DCB
static int qed_dcbx_query_params(struct qed_hwfn *p_hwfn,
struct qed_dcbx_get *p_get,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
index 5feb90e..a4d688c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
@@ -123,4 +123,7 @@ int qed_dcbx_config_params(struct qed_hwfn *,
void qed_dcbx_set_pf_update_params(struct qed_dcbx_results *p_src,
struct pf_update_ramrod_data *p_dest);
+#define QED_DCBX_DEFAULT_TC 0
+
+u8 qed_dcbx_get_priority_tc(struct qed_hwfn *p_hwfn, u8 pri);
#endif
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v3 2/3] qed: Add a flag which indicates if offload TC is set
From: Denis Bolotin @ 2018-08-07 12:48 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin, Michal Kalderon, Ariel Elior
In-Reply-To: <20180807124810.17386-1-denis.bolotin@cavium.com>
Distinguish not set offload_tc from offload_tc 0 and add getters and
setters.
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed.h | 3 +++
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 32 +++++++++++++++++++++++++-----
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 3 ++-
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed.h b/drivers/net/ethernet/qlogic/qed/qed.h
index 1dfaccd..f916f13 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -336,6 +336,7 @@ struct qed_hw_info {
*/
u8 num_active_tc;
u8 offload_tc;
+ bool offload_tc_set;
u32 concrete_fid;
u16 opaque_fid;
@@ -921,4 +922,6 @@ void qed_get_protocol_stats(struct qed_dev *cdev,
int qed_mfw_fill_tlv_data(struct qed_hwfn *hwfn,
enum qed_mfw_tlv_type type,
union qed_mfw_tlv_data *tlv_data);
+
+void qed_hw_info_set_offload_tc(struct qed_hw_info *p_info, u8 tc);
#endif /* _QED_H */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 86307b9..6bb76e6 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -208,7 +208,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
/* QM reconf data */
if (p_info->personality == personality)
- p_info->offload_tc = tc;
+ qed_hw_info_set_offload_tc(p_info, tc);
}
/* Update app protocol data and hw_info fields with the TLV info */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 6a0b46f..a8e7683 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -394,7 +394,25 @@ static void qed_init_qm_advance_vport(struct qed_hwfn *p_hwfn)
/* defines for pq init */
#define PQ_INIT_DEFAULT_WRR_GROUP 1
#define PQ_INIT_DEFAULT_TC 0
-#define PQ_INIT_OFLD_TC (p_hwfn->hw_info.offload_tc)
+
+void qed_hw_info_set_offload_tc(struct qed_hw_info *p_info, u8 tc)
+{
+ p_info->offload_tc = tc;
+ p_info->offload_tc_set = true;
+}
+
+static bool qed_is_offload_tc_set(struct qed_hwfn *p_hwfn)
+{
+ return p_hwfn->hw_info.offload_tc_set;
+}
+
+static u32 qed_get_offload_tc(struct qed_hwfn *p_hwfn)
+{
+ if (qed_is_offload_tc_set(p_hwfn))
+ return p_hwfn->hw_info.offload_tc;
+
+ return PQ_INIT_DEFAULT_TC;
+}
static void qed_init_qm_pq(struct qed_hwfn *p_hwfn,
struct qed_qm_info *qm_info,
@@ -538,7 +556,8 @@ static void qed_init_qm_pure_ack_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_ACK, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_SHARE_VPORT);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_SHARE_VPORT);
}
static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
@@ -549,7 +568,8 @@ static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_OFLD, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_SHARE_VPORT);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_SHARE_VPORT);
}
static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
@@ -560,7 +580,8 @@ static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_LLT, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_SHARE_VPORT);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_SHARE_VPORT);
}
static void qed_init_qm_mcos_pqs(struct qed_hwfn *p_hwfn)
@@ -601,7 +622,8 @@ static void qed_init_qm_rl_pqs(struct qed_hwfn *p_hwfn)
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_RLS, qm_info->num_pqs);
for (pf_rls_idx = 0; pf_rls_idx < num_pf_rls; pf_rls_idx++)
- qed_init_qm_pq(p_hwfn, qm_info, PQ_INIT_OFLD_TC, PQ_INIT_PF_RL);
+ qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
+ PQ_INIT_PF_RL);
}
static void qed_init_qm_pq_params(struct qed_hwfn *p_hwfn)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 8e4f60e..d89a0e2 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1552,7 +1552,8 @@ void qed_mcp_read_ufp_config(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
if (p_hwfn->ufp_info.mode == QED_UFP_MODE_VNIC_BW) {
p_hwfn->qm_info.ooo_tc = p_hwfn->ufp_info.tc;
- p_hwfn->hw_info.offload_tc = p_hwfn->ufp_info.tc;
+ qed_hw_info_set_offload_tc(&p_hwfn->hw_info,
+ p_hwfn->ufp_info.tc);
qed_qm_reconf(p_hwfn, p_ptt);
} else if (p_hwfn->ufp_info.mode == QED_UFP_MODE_ETS) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v3 3/3] qed: Add Multi-TC RoCE support
From: Denis Bolotin @ 2018-08-07 12:48 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin, Michal Kalderon, Ariel Elior
In-Reply-To: <20180807124810.17386-1-denis.bolotin@cavium.com>
RoCE qps use a pair of physical queues (pq) received from the Queue Manager
(QM) - an offload queue (OFLD) and a low latency queue (LLT). The QM block
creates a pq for each TC, and allows RoCE qps to ask for a pq with a
specific TC. As a result, qps with different VLAN priorities can be mapped
to different TCs, and employ features such as PFC and ETS.
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed.h | 10 +++-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 89 +++++++++++++++++++++++++-----
drivers/net/ethernet/qlogic/qed/qed_roce.c | 54 ++++++++++++------
3 files changed, 121 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed.h b/drivers/net/ethernet/qlogic/qed/qed.h
index f916f13..a60e1c8 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -338,6 +338,9 @@ struct qed_hw_info {
u8 offload_tc;
bool offload_tc_set;
+ bool multi_tc_roce_en;
+#define IS_QED_MULTI_TC_ROCE(p_hwfn) (((p_hwfn)->hw_info.multi_tc_roce_en))
+
u32 concrete_fid;
u16 opaque_fid;
u16 ovlan;
@@ -400,8 +403,8 @@ struct qed_qm_info {
u16 start_pq;
u8 start_vport;
u16 pure_lb_pq;
- u16 offload_pq;
- u16 low_latency_pq;
+ u16 first_ofld_pq;
+ u16 first_llt_pq;
u16 pure_ack_pq;
u16 ooo_pq;
u16 first_vf_pq;
@@ -882,11 +885,14 @@ void qed_set_fw_mac_addr(__le16 *fw_msb,
#define PQ_FLAGS_OFLD (BIT(5))
#define PQ_FLAGS_VFS (BIT(6))
#define PQ_FLAGS_LLT (BIT(7))
+#define PQ_FLAGS_MTC (BIT(8))
/* physical queue index for cm context intialization */
u16 qed_get_cm_pq_idx(struct qed_hwfn *p_hwfn, u32 pq_flags);
u16 qed_get_cm_pq_idx_mcos(struct qed_hwfn *p_hwfn, u8 tc);
u16 qed_get_cm_pq_idx_vf(struct qed_hwfn *p_hwfn, u16 vf);
+u16 qed_get_cm_pq_idx_ofld_mtc(struct qed_hwfn *p_hwfn, u8 tc);
+u16 qed_get_cm_pq_idx_llt_mtc(struct qed_hwfn *p_hwfn, u8 tc);
#define QED_LEADING_HWFN(dev) (&dev->hwfns[0])
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index a8e7683..d1ae11a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -215,6 +215,8 @@ static u32 qed_get_pq_flags(struct qed_hwfn *p_hwfn)
break;
case QED_PCI_ETH_ROCE:
flags |= PQ_FLAGS_MCOS | PQ_FLAGS_OFLD | PQ_FLAGS_LLT;
+ if (IS_QED_MULTI_TC_ROCE(p_hwfn))
+ flags |= PQ_FLAGS_MTC;
break;
case QED_PCI_ETH_IWARP:
flags |= PQ_FLAGS_MCOS | PQ_FLAGS_ACK | PQ_FLAGS_OOO |
@@ -241,6 +243,16 @@ static u16 qed_init_qm_get_num_vfs(struct qed_hwfn *p_hwfn)
p_hwfn->cdev->p_iov_info->total_vfs : 0;
}
+static u8 qed_init_qm_get_num_mtc_tcs(struct qed_hwfn *p_hwfn)
+{
+ u32 pq_flags = qed_get_pq_flags(p_hwfn);
+
+ if (!(PQ_FLAGS_MTC & pq_flags))
+ return 1;
+
+ return qed_init_qm_get_num_tcs(p_hwfn);
+}
+
#define NUM_DEFAULT_RLS 1
static u16 qed_init_qm_get_num_pf_rls(struct qed_hwfn *p_hwfn)
@@ -282,8 +294,11 @@ static u16 qed_init_qm_get_num_pqs(struct qed_hwfn *p_hwfn)
(!!(PQ_FLAGS_MCOS & pq_flags)) *
qed_init_qm_get_num_tcs(p_hwfn) +
(!!(PQ_FLAGS_LB & pq_flags)) + (!!(PQ_FLAGS_OOO & pq_flags)) +
- (!!(PQ_FLAGS_ACK & pq_flags)) + (!!(PQ_FLAGS_OFLD & pq_flags)) +
- (!!(PQ_FLAGS_LLT & pq_flags)) +
+ (!!(PQ_FLAGS_ACK & pq_flags)) +
+ (!!(PQ_FLAGS_OFLD & pq_flags)) *
+ qed_init_qm_get_num_mtc_tcs(p_hwfn) +
+ (!!(PQ_FLAGS_LLT & pq_flags)) *
+ qed_init_qm_get_num_mtc_tcs(p_hwfn) +
(!!(PQ_FLAGS_VFS & pq_flags)) * qed_init_qm_get_num_vfs(p_hwfn);
}
@@ -474,9 +489,9 @@ static u16 *qed_init_qm_get_idx_from_flags(struct qed_hwfn *p_hwfn,
case PQ_FLAGS_ACK:
return &qm_info->pure_ack_pq;
case PQ_FLAGS_OFLD:
- return &qm_info->offload_pq;
+ return &qm_info->first_ofld_pq;
case PQ_FLAGS_LLT:
- return &qm_info->low_latency_pq;
+ return &qm_info->first_llt_pq;
case PQ_FLAGS_VFS:
return &qm_info->first_vf_pq;
default:
@@ -525,6 +540,28 @@ u16 qed_get_cm_pq_idx_vf(struct qed_hwfn *p_hwfn, u16 vf)
return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_VFS) + vf;
}
+u16 qed_get_cm_pq_idx_ofld_mtc(struct qed_hwfn *p_hwfn, u8 tc)
+{
+ u16 first_ofld_pq, pq_offset;
+
+ first_ofld_pq = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_OFLD);
+ pq_offset = (tc < qed_init_qm_get_num_mtc_tcs(p_hwfn)) ?
+ tc : PQ_INIT_DEFAULT_TC;
+
+ return first_ofld_pq + pq_offset;
+}
+
+u16 qed_get_cm_pq_idx_llt_mtc(struct qed_hwfn *p_hwfn, u8 tc)
+{
+ u16 first_llt_pq, pq_offset;
+
+ first_llt_pq = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_LLT);
+ pq_offset = (tc < qed_init_qm_get_num_mtc_tcs(p_hwfn)) ?
+ tc : PQ_INIT_DEFAULT_TC;
+
+ return first_llt_pq + pq_offset;
+}
+
/* Functions for creating specific types of pqs */
static void qed_init_qm_lb_pq(struct qed_hwfn *p_hwfn)
{
@@ -560,6 +597,20 @@ static void qed_init_qm_pure_ack_pq(struct qed_hwfn *p_hwfn)
PQ_INIT_SHARE_VPORT);
}
+static void qed_init_qm_mtc_pqs(struct qed_hwfn *p_hwfn)
+{
+ u8 num_tcs = qed_init_qm_get_num_mtc_tcs(p_hwfn);
+ struct qed_qm_info *qm_info = &p_hwfn->qm_info;
+ u8 tc;
+
+ /* override pq's TC if offload TC is set */
+ for (tc = 0; tc < num_tcs; tc++)
+ qed_init_qm_pq(p_hwfn, qm_info,
+ qed_is_offload_tc_set(p_hwfn) ?
+ p_hwfn->hw_info.offload_tc : tc,
+ PQ_INIT_SHARE_VPORT);
+}
+
static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
{
struct qed_qm_info *qm_info = &p_hwfn->qm_info;
@@ -568,8 +619,7 @@ static void qed_init_qm_offload_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_OFLD, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
- PQ_INIT_SHARE_VPORT);
+ qed_init_qm_mtc_pqs(p_hwfn);
}
static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
@@ -580,8 +630,7 @@ static void qed_init_qm_low_latency_pq(struct qed_hwfn *p_hwfn)
return;
qed_init_qm_set_idx(p_hwfn, PQ_FLAGS_LLT, qm_info->num_pqs);
- qed_init_qm_pq(p_hwfn, qm_info, qed_get_offload_tc(p_hwfn),
- PQ_INIT_SHARE_VPORT);
+ qed_init_qm_mtc_pqs(p_hwfn);
}
static void qed_init_qm_mcos_pqs(struct qed_hwfn *p_hwfn)
@@ -664,12 +713,19 @@ static int qed_init_qm_sanity(struct qed_hwfn *p_hwfn)
return -EINVAL;
}
- if (qed_init_qm_get_num_pqs(p_hwfn) > RESC_NUM(p_hwfn, QED_PQ)) {
- DP_ERR(p_hwfn, "requested amount of pqs exceeds resource\n");
- return -EINVAL;
+ if (qed_init_qm_get_num_pqs(p_hwfn) <= RESC_NUM(p_hwfn, QED_PQ))
+ return 0;
+
+ if (QED_IS_ROCE_PERSONALITY(p_hwfn)) {
+ p_hwfn->hw_info.multi_tc_roce_en = 0;
+ DP_NOTICE(p_hwfn,
+ "multi-tc roce was disabled to reduce requested amount of pqs\n");
+ if (qed_init_qm_get_num_pqs(p_hwfn) <= RESC_NUM(p_hwfn, QED_PQ))
+ return 0;
}
- return 0;
+ DP_ERR(p_hwfn, "requested amount of pqs exceeds resource\n");
+ return -EINVAL;
}
static void qed_dp_init_qm_params(struct qed_hwfn *p_hwfn)
@@ -683,11 +739,13 @@ static void qed_dp_init_qm_params(struct qed_hwfn *p_hwfn)
/* top level params */
DP_VERBOSE(p_hwfn,
NETIF_MSG_HW,
- "qm init top level params: start_pq %d, start_vport %d, pure_lb_pq %d, offload_pq %d, pure_ack_pq %d\n",
+ "qm init top level params: start_pq %d, start_vport %d, pure_lb_pq %d, offload_pq %d, llt_pq %d, pure_ack_pq %d\n",
qm_info->start_pq,
qm_info->start_vport,
qm_info->pure_lb_pq,
- qm_info->offload_pq, qm_info->pure_ack_pq);
+ qm_info->first_ofld_pq,
+ qm_info->first_llt_pq,
+ qm_info->pure_ack_pq);
DP_VERBOSE(p_hwfn,
NETIF_MSG_HW,
"ooo_pq %d, first_vf_pq %d, num_pqs %d, num_vf_pqs %d, num_vports %d, max_phys_tcs_per_port %d\n",
@@ -2920,6 +2978,9 @@ static void qed_get_eee_caps(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
p_hwfn->hw_info.personality = protocol;
}
+ if (QED_IS_ROCE_PERSONALITY(p_hwfn))
+ p_hwfn->hw_info.multi_tc_roce_en = 1;
+
p_hwfn->hw_info.num_hw_tc = NUM_PHYS_TCS_4PORT_K2;
p_hwfn->hw_info.num_active_tc = 1;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c b/drivers/net/ethernet/qlogic/qed/qed_roce.c
index ada4c18..7d7a64c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
@@ -44,8 +44,10 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/string.h>
+#include <linux/if_vlan.h>
#include "qed.h"
#include "qed_cxt.h"
+#include "qed_dcbx.h"
#include "qed_hsi.h"
#include "qed_hw.h"
#include "qed_init_ops.h"
@@ -231,16 +233,33 @@ static void qed_roce_set_real_cid(struct qed_hwfn *p_hwfn, u32 cid)
spin_unlock_bh(&p_hwfn->p_rdma_info->lock);
}
+static u8 qed_roce_get_qp_tc(struct qed_hwfn *p_hwfn, struct qed_rdma_qp *qp)
+{
+ u8 pri, tc = 0;
+
+ if (qp->vlan_id) {
+ pri = (qp->vlan_id & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+ tc = qed_dcbx_get_priority_tc(p_hwfn, pri);
+ }
+
+ DP_VERBOSE(p_hwfn, QED_MSG_SP,
+ "qp icid %u tc: %u (vlan priority %s)\n",
+ qp->icid, tc, qp->vlan_id ? "enabled" : "disabled");
+
+ return tc;
+}
+
static int qed_roce_sp_create_responder(struct qed_hwfn *p_hwfn,
struct qed_rdma_qp *qp)
{
struct roce_create_qp_resp_ramrod_data *p_ramrod;
+ u16 regular_latency_queue, low_latency_queue;
struct qed_sp_init_data init_data;
enum roce_flavor roce_flavor;
struct qed_spq_entry *p_ent;
- u16 regular_latency_queue;
enum protocol_type proto;
int rc;
+ u8 tc;
DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "icid = %08x\n", qp->icid);
@@ -324,12 +343,17 @@ static int qed_roce_sp_create_responder(struct qed_hwfn *p_hwfn,
p_ramrod->cq_cid = cpu_to_le32((p_hwfn->hw_info.opaque_fid << 16) |
qp->rq_cq_id);
- regular_latency_queue = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_OFLD);
-
+ tc = qed_roce_get_qp_tc(p_hwfn, qp);
+ regular_latency_queue = qed_get_cm_pq_idx_ofld_mtc(p_hwfn, tc);
+ low_latency_queue = qed_get_cm_pq_idx_llt_mtc(p_hwfn, tc);
+ DP_VERBOSE(p_hwfn, QED_MSG_SP,
+ "qp icid %u pqs: regular_latency %u low_latency %u\n",
+ qp->icid, regular_latency_queue - CM_TX_PQ_BASE,
+ low_latency_queue - CM_TX_PQ_BASE);
p_ramrod->regular_latency_phy_queue =
cpu_to_le16(regular_latency_queue);
p_ramrod->low_latency_phy_queue =
- cpu_to_le16(regular_latency_queue);
+ cpu_to_le16(low_latency_queue);
p_ramrod->dpi = cpu_to_le16(qp->dpi);
@@ -345,11 +369,6 @@ static int qed_roce_sp_create_responder(struct qed_hwfn *p_hwfn,
qp->stats_queue;
rc = qed_spq_post(p_hwfn, p_ent, NULL);
-
- DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
- "rc = %d regular physical queue = 0x%x\n", rc,
- regular_latency_queue);
-
if (rc)
goto err;
@@ -375,12 +394,13 @@ static int qed_roce_sp_create_requester(struct qed_hwfn *p_hwfn,
struct qed_rdma_qp *qp)
{
struct roce_create_qp_req_ramrod_data *p_ramrod;
+ u16 regular_latency_queue, low_latency_queue;
struct qed_sp_init_data init_data;
enum roce_flavor roce_flavor;
struct qed_spq_entry *p_ent;
- u16 regular_latency_queue;
enum protocol_type proto;
int rc;
+ u8 tc;
DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "icid = %08x\n", qp->icid);
@@ -453,12 +473,17 @@ static int qed_roce_sp_create_requester(struct qed_hwfn *p_hwfn,
p_ramrod->cq_cid =
cpu_to_le32((p_hwfn->hw_info.opaque_fid << 16) | qp->sq_cq_id);
- regular_latency_queue = qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_OFLD);
-
+ tc = qed_roce_get_qp_tc(p_hwfn, qp);
+ regular_latency_queue = qed_get_cm_pq_idx_ofld_mtc(p_hwfn, tc);
+ low_latency_queue = qed_get_cm_pq_idx_llt_mtc(p_hwfn, tc);
+ DP_VERBOSE(p_hwfn, QED_MSG_SP,
+ "qp icid %u pqs: regular_latency %u low_latency %u\n",
+ qp->icid, regular_latency_queue - CM_TX_PQ_BASE,
+ low_latency_queue - CM_TX_PQ_BASE);
p_ramrod->regular_latency_phy_queue =
cpu_to_le16(regular_latency_queue);
p_ramrod->low_latency_phy_queue =
- cpu_to_le16(regular_latency_queue);
+ cpu_to_le16(low_latency_queue);
p_ramrod->dpi = cpu_to_le16(qp->dpi);
@@ -471,9 +496,6 @@ static int qed_roce_sp_create_requester(struct qed_hwfn *p_hwfn,
qp->stats_queue;
rc = qed_spq_post(p_hwfn, p_ent, NULL);
-
- DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "rc = %d\n", rc);
-
if (rc)
goto err;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v3 0/3] qed: Add Multi-TC RoCE support
From: Denis Bolotin @ 2018-08-07 12:48 UTC (permalink / raw)
To: davem, netdev; +Cc: Denis Bolotin
Hi Dave,
This patch series adds support for multiple concurrent traffic classes for RoCE.
The first three patches enable the required parts of the driver to learn the TC
configuration, and the last one makes use of it to enable the feature.
Please consider applying this to net-next.
V1->V2:
-------
Avoid allocation in qed_dcbx_get_priority_tc().
Move qed_dcbx_get_priority_tc() out of CONFIG_DCB section since it doesn't call
qed_dcbx_query_params() anymore.
v2->V3:
-------
patch 1/3:
qed_dcbx_get_priority_tc() always returns a valid TC by value. In error cases,
it returns QED_DCBX_DEFAULT_TC (currently defined 0).
patch 3/3:
Cosmetic changes in qed_dev.c.
Denis Bolotin (3):
qed: Add DCBX API - qed_dcbx_get_priority_tc()
qed: Add a flag which indicates if offload TC is set
qed: Add Multi-TC RoCE support
drivers/net/ethernet/qlogic/qed/qed.h | 13 +++-
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 20 ++++-
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 3 +
drivers/net/ethernet/qlogic/qed/qed_dev.c | 113 +++++++++++++++++++++++++----
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 3 +-
drivers/net/ethernet/qlogic/qed/qed_roce.c | 54 ++++++++++----
6 files changed, 171 insertions(+), 35 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper
From: Greg KH @ 2018-08-07 13:22 UTC (permalink / raw)
To: David Woodhouse
Cc: davem, edumazet, juha-matti.tilli, ycheng, soheil, netdev,
eric.dumazet, dwmw2, jdw
In-Reply-To: <1533373800-22712-1-git-send-email-dwmw@amazon.co.uk>
On Sat, Aug 04, 2018 at 10:10:00AM +0100, David Woodhouse wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit 58152ecbbcc6a0ce7fddd5bf5f6ee535834ece0c upstream.
>
> In case skb in out_or_order_queue is the result of
> multiple skbs coalescing, we would like to get a proper gso_segs
> counter tracking, so that future tcp_drop() can report an accurate
> number.
>
> I chose to not implement this tracking for skbs in receive queue,
> since they are not dropped, unless socket is disconnected.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> net/ipv4/tcp_input.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
Now applied, thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order
From: Stefano Brivio @ 2018-08-07 13:31 UTC (permalink / raw)
To: Pravin Shelar
Cc: Matteo Croce, Justin Pettit, Greg Rose, Ben Pfaff, netdev,
ovs dev, Jiri Benc, Aaron
In-Reply-To: <CAOrHB_B4qhwMuhWFhQco+pPyPxcSpOPswMpNyEEq2n+mET-mXA@mail.gmail.com>
Hi Pravin,
On Tue, 31 Jul 2018 16:12:03 -0700
Pravin Shelar <pshelar@ovn.org> wrote:
> Rather than reducing number of thread down to 1, we could find better
> number of FDs per port.
> How about this simple solution:
> 1. Allocate (N * P) FDs as long as it is under FD limit.
> 2. If FD limit (-EMFILE) is hit reduce N value by half and repeat step 1.
I still see a few quantitative issues with this approach, other than
Ben's observation about design (which, by the way, looks entirely
reasonable to me).
We're talking about a disproportionate amount of sockets in any case.
We can have up to 2^16 vports here, with 5k vports being rather common,
and for any reasonable value of N that manages somehow to perturbate the
distribution of upcalls per thread, we are talking about something well
in excess of 100k sockets. I think this doesn't really scale.
With the current value for N (3/4 * number of threads) this can even get
close to /proc/sys/fs/file-max on some systems, and there raising the
number of allowed file descriptors for ovs-vswitchd isn't a solution
anymore.
I would instead try to address the concerns that you had about the
original patch adding fairness in the kernel, rather than trying to
make the issue appear less severe in ovs-vswitchd.
--
Stefano
^ permalink raw reply
* Re: [PATCH v3 net-next 5/9] net: stmmac: Add MDIO related functions for XGMAC2
From: Jose Abreu @ 2018-08-07 13:35 UTC (permalink / raw)
To: Florian Fainelli, Jose Abreu, netdev
Cc: David S. Miller, Joao Pinto, Giuseppe Cavallaro, Alexandre Torgue,
Andrew Lunn
In-Reply-To: <C540FD04-8429-41E3-9C2C-C21CEAF8030D@gmail.com>
Hi Florian,
On 06-08-2018 16:25, Florian Fainelli wrote:
> On August 6, 2018 12:59:54 AM PDT, Jose Abreu <Jose.Abreu@synopsys.com> wrote:
>> On 03-08-2018 20:06, Florian Fainelli wrote:
>>> On 08/03/2018 08:50 AM, Jose Abreu wrote:
>>>> Add the MDIO related funcionalities for the new IP block XGMAC2.
>>>>
>>>> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
>>>> Cc: David S. Miller <davem@davemloft.net>
>>>> Cc: Joao Pinto <jpinto@synopsys.com>
>>>> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>>>> Cc: Alexandre Torgue <alexandre.torgue@st.com>
>>>> Cc: Andrew Lunn <andrew@lunn.ch>
>>>> ---
>>>> +satic int stmmac_xgmac2_c22_format(struct stmmac_priv *priv, int
>> phyaddr,
>>>> + int phyreg, u32 *hw_addr)
>>>> +{
>>>> + unsigned int mii_data = priv->hw->mii.data;
>>>> + u32 tmp;
>>>> +
>>>> + /* HW does not support C22 addr >= 4 */
>>>> + if (phyaddr >= 4)
>>>> + return -ENODEV;
>>> It would be nice if this could be moved at probe time so you don't
>> have
>>> to wait until you connect to the PHY, read its PHY OUI and find out
>> it
>>> has a MDIO address >= 4. Not a blocker, but something that could be
>>> improved further on.
>>>
>>> In premise you could even scan the MDIO bus' device tree node, and
>> find
>>> that out ahead of time.
>> Oh, but I use phylib ... I only provide the read/write callbacks
>> so I think we should avoid duplicating the code that's already in
>> the phylib ... No?
> You can always extract the code that scans a MDIO bus into a helper function and make it parametrized with a callback of some kind. In that case I would be fine with you open coding the MDIO bus scan to find out if there is an address >= 4.
Sorry but I dont' think thats the best solution because
of_mdiobus_register() already scans the bus. Duplicating this
should be avoided, no?
Note all of this is probably never needed because stmmac just
picks the first phy it finds, if phy_addr is not specified ...
>
>>>> + /* Wait until any existing MII operation is complete */
>>>> + if (readl_poll_timeout(priv->ioaddr + mii_data, tmp,
>>>> + !(tmp & MII_XGMAC_BUSY), 100, 10000))
>>>> + return -EBUSY;
>>>> +
>>>> + /* Set port as Clause 22 */
>>>> + tmp = readl(priv->ioaddr + XGMAC_MDIO_C22P);
>>>> + tmp |= BIT(phyaddr);
>>> Since the registers are being Read/Modify/Write here, don't you need
>> to
>>> clear the previous address bits as well?
>>>
>>> You probably did not encounter any problems in your testing if you
>> had
>>> only one PHY on the MDIO bus, but this is not something that is
>>> necessarily true, e.g: if you have an Ethernet switch, several MDIO
>> bus
>>> addresses are going to be responding.
>>>
>>> Your MDIO bus implementation must be able to support one transaction
>>> with one PHY address and the next transaction with another PHY
>> address ,
>>> etc...
>>>
>>> That is something that should be easy to fix and be resubmitted as
>> part
>>> of v4.
>> I'm not following you here... I only set/unset the bit for the
>> corresponding phyaddr that phylib wants to read/write. Why would
>> I clear the remaining addresses?
> Because this is all about transactions, the HW must be in a state that it will be able to perform that transaction correctly. So here for instance if you needed to support a C45 transaction you would have to clear that bit for that particular PHY address. Since you don't appear to support those yet then yes the code appears fine though it would not hurt if you did clear all other PHY's c22 bits to make it clear what this does.
I can't test C45 right now but I will in a near future. In that
case then we will need to support C22 and C45 so I may want to
only set one bit for a specific phy that only supports c22.
Thanks and Best Regards,
Jose Miguel Abreu
>
^ permalink raw reply
* Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order
From: Stefano Brivio @ 2018-08-07 13:39 UTC (permalink / raw)
To: Pravin Shelar
Cc: Matteo Croce, Justin Pettit, Greg Rose, Ben Pfaff, netdev,
ovs dev, Jiri Benc, Aaron
In-Reply-To: <20180807153111.53b0da8d@epycfail>
On Tue, 7 Aug 2018 15:31:11 +0200
Stefano Brivio <sbrivio@redhat.com> wrote:
> I would instead try to address the concerns that you had about the
> original patch adding fairness in the kernel, rather than trying to
> make the issue appear less severe in ovs-vswitchd.
And, by the way, if we introduce a way to configure the possible
fairness algorithms via netlink, we can also rather easily allow
ovs-vswitchd to disable fairness on kernel side altogether, should it
be needed.
--
Stefano
^ 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