* About 1000Mbps capability for the GMAC of RK3288
From: Randy Li @ 2016-09-26 2:34 UTC (permalink / raw)
To: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, peppe.cavallaro, alexandre.torgue,
netdev
In-Reply-To: <3b81dc49-06ce-30d2-fc35-ee5a3a691e6a@rock-chips.com>
I have confirmed the 1000Mbps won't work with kernel 4.4, I have to
disable it in dts.
The TRM shows that it may not support 1000Mbps, as the gmac_speed in
GRF_SOC_CON1 is just a bit length flag.
Also I have test the performance at the firefly plus with upstream
kernel, it even looks bad at 100Mpbs mode, only 5~6 MBytes per second. I
wonder whether it is the hardware design problem or some problem in
driver, I would report if I got more information.
-------- Forwarded Message --------
Subject: About 1000Mbps with RK3288 and performance
Date: Tue, 20 Sep 2016 09:31:57 +0800
From: Randy Li <randy.li@rock-chips.com>
Organization: Fuzhou Rockchip
To: david.wu@rock-chips.com
CC: roger.chen@rock-chips.com
Hello Wu
Have you guys confirmed the RK3288 EVB with 1000Mbps network? I meet
this issue in the weekend. The kernel is 4.4, when I connected the board
into a 1000Mbps switch(Dell PowerConnect Serial), the speed negatived
1000Mbps at both side(I checked with console in switch), but the network
can't work at all. I have downgrade the speed to 100Mbps or packages
loss is nearly 100%.
Also I have been reported with performance of ethernet in Upstream
kernel, it could barely 5-6MBytes in my test, do you have some idea
about this?
You could dial internal number 8308 to talk with me.
Yours Randy
--
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================
^ permalink raw reply
* RE: [v12, 0/8] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-09-26 3:14 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Scott Wood,
Arnd Bergmann
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
Rob Herring, Russell King, Jochen Friedrich, Joerg Roedel,
Claudiu Manoil, Bhupesh Sharma
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Any comments about this version patchset ?
:)
> -----Original Message-----
> From: Yangbo Lu [mailto:yangbo.lu-3arQi8VN3Tc@public.gmane.org]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
>
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++++++
> drivers/clk/clk-qoriq.c | 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257
> +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++----
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h | 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-) rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH][V2] cxgb4: fix -ve error check on a signed iq
From: David Miller @ 2016-09-26 3:40 UTC (permalink / raw)
To: colin.king; +Cc: hariprasad, netdev, linux-kernel
In-Reply-To: <20160925211445.11234-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sun, 25 Sep 2016 14:14:45 -0700
> From: Colin Ian King <colin.king@canonical.com>
>
> iq is unsigned, so the error check for iq < 0 has no effect so errors
> can slip past this check. Fix this by making iq signed and also
> get_filter_steerq return a signed int so a -ve error can be returned.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route
From: David Miller @ 2016-09-26 3:42 UTC (permalink / raw)
To: nikolay; +Cc: netdev, tgraf, roopa, sharpd
In-Reply-To: <1474837711-19277-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Sun, 25 Sep 2016 23:08:31 +0200
> Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid
> instead of the previous dst_pid which was copied from in_skb's portid.
> Since the skb is new the portid is 0 at that point so the packets are sent
> to the kernel and we get scheduling while atomic or a deadlock (depending
> on where it happens) by trying to acquire rtnl two times.
> Also since this is RTM_GETROUTE, it can be triggered by a normal user.
>
> Here's the sleeping while atomic trace:
...
> Fixes: 2942e9005056 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
This approach looks fine to me, applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net: smc91x: take into account register shift
From: David Miller @ 2016-09-26 3:46 UTC (permalink / raw)
To: robert.jarzmik; +Cc: nico, netdev, linux-kernel
In-Reply-To: <1474837245-32512-1-git-send-email-robert.jarzmik@free.fr>
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Sun, 25 Sep 2016 23:00:45 +0200
> This aligns smc91x with its cousin, namely smc911x.c.
> This also allows the driver to run also in a device-tree based lubbock
> board build, on which it was tested.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH -next] be2net: fix non static symbol warnings
From: David Miller @ 2016-09-26 3:48 UTC (permalink / raw)
To: weiyj.lk
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
weiyongjun1, netdev
In-Reply-To: <1474818036-18872-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Sun, 25 Sep 2016 15:40:36 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warnings:
>
> drivers/net/ethernet/emulex/benet/be_main.c:47:25: warning:
> symbol 'be_err_recovery_workq' was not declared. Should it be static?
> drivers/net/ethernet/emulex/benet/be_main.c:63:25: warning:
> symbol 'be_wq' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] net: dsa: mv88e6xxx: fix non static symbol warnings
From: David Miller @ 2016-09-26 3:49 UTC (permalink / raw)
To: weiyj.lk; +Cc: andrew, vivien.didelot, f.fainelli, weiyongjun1, netdev
In-Reply-To: <1474818182-19097-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Sun, 25 Sep 2016 15:43:02 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warnings:
>
> drivers/net/dsa/mv88e6xxx/chip.c:219:5: warning:
> symbol 'mv88e6xxx_port_read' was not declared. Should it be static?
> drivers/net/dsa/mv88e6xxx/chip.c:227:5: warning:
> symbol 'mv88e6xxx_port_write' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: pull request: bluetooth-next 2016-09-25
From: David Miller @ 2016-09-26 3:53 UTC (permalink / raw)
To: johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160925124238.GA19411-ae+CCJ+dGXjCW7GOcxkI+ioyn5ZhHHrn@public.gmane.org>
From: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sun, 25 Sep 2016 15:42:38 +0300
> Here are a few more Bluetooth & 802.15.4 patches for the 4.9 kernel that
> have popped up during the past week:
>
> - New USB ID for QCA_ROME Bluetooth device
> - NULL pointer dereference fix for Bluetooth mgmt sockets
> - Fixes for BCSP driver
> - Fix for updating LE scan response
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [PATCH v5 02/16] IB/pvrdma: Add user-level shared functions
From: Adit Ranadive @ 2016-09-26 4:22 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <20160925072624.GV4088-2ukJVAZIZ/Y@public.gmane.org>
On Sun, Sep 25 2016 at 10:26:24AM +0300, Leon Romanovsky wrote:
> > On Sat, Sep 24, 2016 at 04:21:26PM -0700, Adit Ranadive wrote:
> > We share some common structures with the user-level driver. This patch adds
> > those structures and shared functions to traverse the QP/CQ rings.
<...>
> > +
> > +#include <linux/types.h>
> > +
> > +#define PVRDMA_UVERBS_ABI_VERSION 3
> > +#define PVRDMA_BOARD_ID 1
> > +#define PVRDMA_REV_ID 1
> >
> > Please don't add defines which you are not using in the library and the
> > two above are not in use.
> >
I'll move these to the pvrdma.h file.
<...>
> > diff --git a/include/uapi/rdma/pvrdma-uapi.h b/include/uapi/rdma/pvrdma-uapi.h
> > new file mode 100644
> > index 0000000..430d8a5
<...>
> > +
> > +#ifndef __PVRDMA_UAPI_H__
> > +#define __PVRDMA_UAPI_H__
> > +
> > +#include <linux/types.h>
> > +
> > +#define PVRDMA_VERSION 17
> >
> > What do you plan to do with this VERSION?
> > How is it related to ABI?
> >
Not related. This is only for the driver to know which APIs to support.
For example, an older driver would still be able to work with a newer
device. I can move this to pvrdma.h as well.
To be honest, I thought I can move this file into the uapi folder since
the structures here are shared with the user-level library. Based on
your comments in this thread and the other ones, I think it makes sense
to move this file back to the pvrdma driver folder and rename it
(pvrdma_wqe.h?) to avoid confusion. There might still be some duplicate
code (especially the UAR offsets and WQE structs) here and in our
user-level library.
Let me know if that makes sense.
> > +
> > +#define PVRDMA_UAR_HANDLE_MASK 0x00FFFFFF /* Bottom 24 bits. */
> > +#define PVRDMA_UAR_QP_OFFSET 0 /* Offset of QP doorbell. */
> > +#define PVRDMA_UAR_QP_SEND BIT(30) /* Send bit. */
> > +#define PVRDMA_UAR_QP_RECV BIT(31) /* Recv bit. */
> > +#define PVRDMA_UAR_CQ_OFFSET 4 /* Offset of CQ doorbell. */
> > +#define PVRDMA_UAR_CQ_ARM_SOL BIT(29) /* Arm solicited bit. */
> > +#define PVRDMA_UAR_CQ_ARM BIT(30) /* Arm bit. */
> > +#define PVRDMA_UAR_CQ_POLL BIT(31) /* Poll bit. */
> > +#define PVRDMA_INVALID_IDX -1 /* Invalid index. */
> >
> > +
> > +/* PVRDMA atomic compare and swap */
> > +struct pvrdma_exp_cmp_swap {
> >
> > _EXP_ looks very similar to MLNX_OFED naming convention.
> >
Yes, the operation was based on that. Any concerns?
I can rename this and the one below.
> > + __u64 swap_val;
> > + __u64 compare_val;
> > + __u64 swap_mask;
> > + __u64 compare_mask;
> > +};
> > +
> > +/* PVRDMA atomic fetch and add */
> > +struct pvrdma_exp_fetch_add {
> >
> > The same as above.
> >
> > + __u64 add_val;
> > + __u64 field_boundary;
> > +};
> > +
> > +/* PVRDMA address vector. */
> > +struct pvrdma_av {
> > + __u32 port_pd;
> > + __u32 sl_tclass_flowlabel;
> > + __u8 dgid[16];
> > + __u8 src_path_bits;
> > + __u8 gid_index;
> > + __u8 stat_rate;
> > + __u8 hop_limit;
> > + __u8 dmac[6];
> > + __u8 reserved[6];
> > +};
> > +
> > +/* PVRDMA scatter/gather entry */
> > +struct pvrdma_sge {
> > + __u64 addr;
> > + __u32 length;
> > + __u32 lkey;
> > +};
> > +
> > +/* PVRDMA receive queue work request */
> > +struct pvrdma_rq_wqe_hdr {
> > + __u64 wr_id; /* wr id */
> > + __u32 num_sge; /* size of s/g array */
> > + __u32 total_len; /* reserved */
> > +};
> > +/* Use pvrdma_sge (ib_sge) for receive queue s/g array elements. */
> > +
> > +/* PVRDMA send queue work request */
> > +struct pvrdma_sq_wqe_hdr {
> > + __u64 wr_id; /* wr id */
> > + __u32 num_sge; /* size of s/g array */
> > + __u32 total_len; /* reserved */
> > + __u32 opcode; /* operation type */
> > + __u32 send_flags; /* wr flags */
> > + union {
> > + __u32 imm_data;
> > + __u32 invalidate_rkey;
> > + } ex;
> > + __u32 reserved;
> > + union {
> > + struct {
> > + __u64 remote_addr;
> > + __u32 rkey;
> > + __u8 reserved[4];
> > + } rdma;
> > + struct {
> > + __u64 remote_addr;
> > + __u64 compare_add;
> > + __u64 swap;
> > + __u32 rkey;
> > + __u32 reserved;
> > + } atomic;
> > + struct {
> > + __u64 remote_addr;
> > + __u32 log_arg_sz;
> > + __u32 rkey;
> > + union {
> > + struct pvrdma_exp_cmp_swap cmp_swap;
> > + struct pvrdma_exp_fetch_add fetch_add;
> > + } wr_data;
> > + } masked_atomics;
> > + struct {
> > + __u64 iova_start;
> > + __u64 pl_pdir_dma;
> > + __u32 page_shift;
> > + __u32 page_list_len;
> > + __u32 length;
> > + __u32 access_flags;
> > + __u32 rkey;
> > + } fast_reg;
> > + struct {
> > + __u32 remote_qpn;
> > + __u32 remote_qkey;
> > + struct pvrdma_av av;
> > + } ud;
> > + } wr;
> > +};
> >
> > No, I have half-baked patch series which refactors this structure in kernel.
> > There is no need to put this structure in UAPI.
> >
This is specific to our device.. We do need to enqueue the WQE in this format
for the device to recognize it. This is the same format that the user-level
library will put the WQE in. As I said above, we can move this to the main
pvrdma driver directory if you prefer.
> > +/* Use pvrdma_sge (ib_sge) for send queue s/g array elements. */
> > +
> > +/* Completion queue element. */
> > +struct pvrdma_cqe {
> > + __u64 wr_id;
> > + __u64 qp;
> > + __u32 opcode;
> > + __u32 status;
> > + __u32 byte_len;
> > + __u32 imm_data;
> > + __u32 src_qp;
> > + __u32 wc_flags;
> > + __u32 vendor_err;
> > + __u16 pkey_index;
> > + __u16 slid;
> > + __u8 sl;
> > + __u8 dlid_path_bits;
> > + __u8 port_num;
> > + __u8 smac[6];
> > + __u8 reserved2[7]; /* Pad to next power of 2 (64). */
> > +};
> > +
> > +struct pvrdma_ring {
> > + atomic_t prod_tail; /* Producer tail. */
> > + atomic_t cons_head; /* Consumer head. */
> > +};
> > +
> > +struct pvrdma_ring_state {
> > + struct pvrdma_ring tx; /* Tx ring. */
> > + struct pvrdma_ring rx; /* Rx ring. */
> > +};
> > +
> > +static inline int pvrdma_idx_valid(__u32 idx, __u32 max_elems)
> > +{
> > + /* Generates fewer instructions than a less-than. */
> > + return (idx & ~((max_elems << 1) - 1)) == 0;
> > +}
> > +
> > +static inline __s32 pvrdma_idx(atomic_t *var, __u32 max_elems)
> > +{
> > + const unsigned int idx = atomic_read(var);
> > +
> > + if (pvrdma_idx_valid(idx, max_elems))
> > + return idx & (max_elems - 1);
> > + return PVRDMA_INVALID_IDX;
> > +}
> > +
> > +static inline void pvrdma_idx_ring_inc(atomic_t *var, __u32 max_elems)
> > +{
> > + __u32 idx = atomic_read(var) + 1; /* Increment. */
> >
> > It is definitely different atomic_read than you expect. From my grep
> > searches on my machine, linux kernel doesn't export in standard headers
> > the atomic_* functions and C has their implementation of that functions.
> >
This would probably change for the user-level library, so no need have this file
in UAPI.
> > +
> > + idx &= (max_elems << 1) - 1; /* Modulo size, flip gen. */
> > + atomic_set(var, idx);
> > +}
> > +
> > +static inline __s32 pvrdma_idx_ring_has_space(const struct pvrdma_ring *r,
> > + __u32 max_elems, __u32 *out_tail)
> > +{
> > + const __u32 tail = atomic_read(&r->prod_tail);
> > + const __u32 head = atomic_read(&r->cons_head);
> > +
> > + if (pvrdma_idx_valid(tail, max_elems) &&
> > + pvrdma_idx_valid(head, max_elems)) {
> > + *out_tail = tail & (max_elems - 1);
> > + return tail != (head ^ max_elems);
> > + }
> > + return PVRDMA_INVALID_IDX;
> > +}
> > +
> > +static inline __s32 pvrdma_idx_ring_has_data(const struct pvrdma_ring *r,
> > + __u32 max_elems, __u32 *out_head)
> > +{
> > + const __u32 tail = atomic_read(&r->prod_tail);
> > + const __u32 head = atomic_read(&r->cons_head);
> > +
> > + if (pvrdma_idx_valid(tail, max_elems) &&
> > + pvrdma_idx_valid(head, max_elems)) {
> > + *out_head = head & (max_elems - 1);
> > + return tail != head;
> > + }
> > + return PVRDMA_INVALID_IDX;
> > +}
> > +
> > +static inline bool pvrdma_idx_ring_is_valid_idx(const struct pvrdma_ring *r,
> > + __u32 max_elems, __u32 *idx)
> > +{
> > + const __u32 tail = atomic_read(&r->prod_tail);
> > + const __u32 head = atomic_read(&r->cons_head);
> > +
> > + if (pvrdma_idx_valid(tail, max_elems) &&
> > + pvrdma_idx_valid(head, max_elems) &&
> > + pvrdma_idx_valid(*idx, max_elems)) {
> > + if (tail > head && (*idx < tail && *idx >= head))
> > + return true;
> > + else if (head > tail && (*idx >= head || *idx < tail))
> > + return true;
> > + }
> > + return false;
> > +}
> > +
> > +#endif /* __PVRDMA_UAPI_H__ */
> >
> > I suggest completely remove this file from UAPI headers folder.
> >
I can move this back to the pvrdma driver folder.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] net/sched: pkt_cls: change tc actions order to be as the user sets
From: Cong Wang @ 2016-09-26 4:31 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Hadar Hen Zion, David S. Miller, Linux Kernel Network Developers,
Or Gerlitz
In-Reply-To: <19723e0f-50b0-77fa-2884-c5bb6e182df9@mojatatu.com>
On Sun, Sep 25, 2016 at 7:39 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 16-09-25 10:08 AM, Hadar Hen Zion wrote:
>>
>> Currently the created tc actions list is reversed against the order
>> set by the user.
>> Change the actions list order to be the same as was set by the user.
>>
>
>
> Did something break? It seems to matter most for dumping. But even that
> didnt breaking. Looking at the latest net tree, i tried:
>
The reason is we use action->order as an nested attribute, so
the order in the list doesn't matter, only action->order itself matters.
See tcf_action_dump():
nest = nla_nest_start(skb, a->order);
^ permalink raw reply
* Re: [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Cong Wang @ 2016-09-26 4:55 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Shmulik Ladkani, David S. Miller, Eric Dumazet,
Linux Kernel Network Developers, Florian Westphal
In-Reply-To: <bd2b555f-cba2-b7bc-1fbe-663da288d8a3@mojatatu.com>
On Sun, Sep 25, 2016 at 6:39 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 16-09-24 08:07 PM, Cong Wang wrote:
>>
>> On Thu, Sep 22, 2016 at 10:11 PM, Shmulik Ladkani
>
>
>>
>> One problem to use your code for us is that, the RX side of veth
>> is inside containers, not visible to outside, perhaps we need some
>> more parameter to tell the netns before the device name/index?
>> Thoughts?
>>
>
> Intriguing - but this would apply for only veth?
Yes, my case is only about veth.
^ permalink raw reply
* Re: [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Cong Wang @ 2016-09-26 4:56 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: Jamal Hadi Salim, David S. Miller, Eric Dumazet,
Linux Kernel Network Developers
In-Reply-To: <20160925205932.57b21e93@halley>
On Sun, Sep 25, 2016 at 10:59 AM, Shmulik Ladkani
<shmulik.ladkani@gmail.com> wrote:
> Hi,
>
> On Sat, 24 Sep 2016 17:07:12 -0700 Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> One problem to use your code for us is that, the RX side of veth
>> is inside containers, not visible to outside, perhaps we need some
>> more parameter to tell the netns before the device name/index?
>> Thoughts?
>
> Well, this is way trickier...
>
> tc_mirred doesn't cope with netns movement of the target device.
> See 'mirred_device_event': upon NETDEV_UNREGISTER the 'tcfm_dev' gets
> nullified.
>
> (dev_change_net_namespace sequence includes NETDEV_UNREGISTER,
> dev_net_set, NETDEV_REGISTER).
>
> As upposed to veth, which keeps the peer netdev pointer (since veth peers
> lifetime is coupled), here in act_mirred we can't easily distinguish a
> "real" NETDEV_UNREGISTER vs a namespace change...
Yeah, isolation is a barrier for this, so we probably can't use
this feature. But I still think it could be useful.
Thanks.
^ permalink raw reply
* Re: [PATCH v5 13/16] IB/pvrdma: Add the main driver module for PVRDMA
From: Adit Ranadive @ 2016-09-26 5:10 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford, linux-rdma, pv-drivers, netdev, linux-pci, jhansen,
asarwade, georgezhang, bryantan
In-Reply-To: <20160925075703.GX4088@leon.nu>
On sun, Sep 25 2016 at 10:57:03AM +0300, Leon Romanovsky wrote:
> On Sat, Sep 24, 2016 at 04:21:37PM -0700, Adit Ranadive wrote:
> > This patch adds the support to register a RDMA device with the kernel RDMA
> > stack as well as a kernel module. This also initializes the underlying
> > virtual PCI device.
> >
> > Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
> > Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
> > Reviewed-by: George Zhang <georgezhang@vmware.com>
> > Reviewed-by: Aditya Sarwade <asarwade@vmware.com>
> > Reviewed-by: Bryan Tan <bryantan@vmware.com>
> > Signed-off-by: Adit Ranadive <aditr@vmware.com>
<...>
> > +
> > +#include <linux/errno.h>
> > +#include <linux/inetdevice.h>
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <rdma/ib_addr.h>
> > +#include <rdma/ib_smi.h>
> > +#include <rdma/ib_user_verbs.h>
> > +#include <net/addrconf.h>
> > +#include <rdma/pvrdma-abi.h>
> > +
> > +#include "pvrdma.h"
> > +
> > +#define DRV_NAME "pvrdma"
> > +#define DRV_VERSION "1.0"
> > +#define DRV_RELDATE "January 1, 2013"
> > +
> > +static const char pvrdma_version[] =
> > + DRV_NAME ": PVRDMA InfiniBand driver v"
> > + DRV_VERSION " (" DRV_RELDATE ")\n";
>
> This is a good example why driver version and reldate are useless in
> kernel. We are in 2016 and not in 2013. All these data are forgotten to
> update right after the developer copied it from other pre-historic driver
> (very common practice in netdev). It is worth to stop to use this totally
> useless defines.
>
Sorry, in our case it was the Mellanox mlx4 driver :). Yeah, I can remove
DRV_VERSION and DRV_RELDATE. I'll keep the MODULE_VERSION since we keep
track of our virtual driver versions that way. So when there are any changes
to our driver we typically bump up the version. Not sure if that's a netdev
or misc device practice and if thats followed here.
<...>
> > +static void pvrdma_get_fw_ver_str(struct ib_device *device, char *str,
> > + size_t str_len)
> > +{
> > + struct pvrdma_dev *dev =
> > + container_of(device, struct pvrdma_dev, ib_dev);
> > + snprintf(str, str_len, "%d.%d.%d\n",
> > + (int) (dev->dsr->caps.fw_ver >> 32),
> > + (int) (dev->dsr->caps.fw_ver >> 16) & 0xffff,
> > + (int) dev->dsr->caps.fw_ver & 0xffff);
> > +}
>
> Yuval already pointed it to you.
> Thanks to Ira, we have general function in core to print FW version.
> Please use them.
>
If you are referring to commit 5fa76c20458518ed6181adddef2e31c5afc0745c
then isnt this is exactly what Ira did for the other providers?
Here, the pvrdma_get_fw_ver_str function is registered as a callback for
the get_dev_fw_str API. Please our pvrdma_register_device function where
we register our callbacks with ib_core:
https://patchwork.kernel.org/patch/9349357/
> > + dev->ib_dev.get_dev_fw_str = pvrdma_get_fw_ver_str;
^ permalink raw reply
* Re: [PATCH v5 16/16] MAINTAINERS: Update for PVRDMA driver
From: Adit Ranadive @ 2016-09-26 5:22 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <20160925073010.GW4088-2ukJVAZIZ/Y@public.gmane.org>
On Sun, Sep 25 2016 at 10:30:10AM +0300, Leon Romanovsky wrote:
> On Sat, Sep 24, 2016 at 04:21:40PM -0700, Adit Ranadive wrote:
> > Add maintainer info for the PVRDMA driver.
> >
> > Reviewed-by: Jorgen Hansen <jhansen-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > Reviewed-by: George Zhang <georgezhang-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > Reviewed-by: Aditya Sarwade <asarwade-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > Reviewed-by: Bryan Tan <bryantan-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > Signed-off-by: Adit Ranadive <aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > ---
> > Changes v4->v5:
> > - Added pvrdma files to common UAPI folder.
> > ---
> > MAINTAINERS | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 87e23cd..5023dc0 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12615,6 +12615,15 @@ S: Maintained
> > F: drivers/scsi/vmw_pvscsi.c
> > F: drivers/scsi/vmw_pvscsi.h
> >
> > +VMWARE PVRDMA DRIVER
> > +M: Adit Ranadive <aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > +M: VMware PV-Drivers <pv-drivers-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > +L: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > +S: Maintained
> > +F: drivers/infiniband/hw/pvrdma/
> > +F: include/uapi/rdma/pvrdma-abi.h
> > +F: include/uapi/rdma/pvrdma-uapi.h
>
> Please remove the last two lines, these files will be maintained by
> Doug.
>
> Thanks
>
Ok. Based on your recent patch series on export vendor specific ABIs,
the ABI files were added to be maintained [1] by individual driver owners.
Is that not the case now?
[1] http://marc.info/?l=linux-rdma&m=147455473718235&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver
From: Adit Ranadive @ 2016-09-26 5:25 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford, linux-rdma, pv-drivers, netdev, linux-pci, jhansen,
asarwade, georgezhang, bryantan
In-Reply-To: <20160925070352.GU4088@leon.nu>
On Sun, Sep 25 2016 at 10:03:52AM +0300, Leon Romanovsky wrote:
> On Sat, Sep 24, 2016 at 04:21:24PM -0700, Adit Ranadive wrote:
>
> <...>
>
> > include/uapi/rdma/pvrdma-abi.h | 99 ++
> > include/uapi/rdma/pvrdma-uapi.h | 255 +++++
>
> As Jason said, you need a very good reason to split and create number of
> files per-driver in UAPI folder.
I can move the pvrdma-uapi.h back to the pvrdma driver folder.
^ permalink raw reply
* Re: [PATCH v5 16/16] MAINTAINERS: Update for PVRDMA driver
From: Leon Romanovsky @ 2016-09-26 5:56 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford, linux-rdma, pv-drivers, netdev, linux-pci, jhansen,
asarwade, georgezhang, bryantan
In-Reply-To: <7ddc5906-6ba8-335e-c0b8-eb60427a1be8@vmware.com>
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
On Sun, Sep 25, 2016 at 10:22:02PM -0700, Adit Ranadive wrote:
> On Sun, Sep 25 2016 at 10:30:10AM +0300, Leon Romanovsky wrote:
> > On Sat, Sep 24, 2016 at 04:21:40PM -0700, Adit Ranadive wrote:
> > > Add maintainer info for the PVRDMA driver.
> > >
> > > Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
> > > Reviewed-by: George Zhang <georgezhang@vmware.com>
> > > Reviewed-by: Aditya Sarwade <asarwade@vmware.com>
> > > Reviewed-by: Bryan Tan <bryantan@vmware.com>
> > > Signed-off-by: Adit Ranadive <aditr@vmware.com>
> > > ---
> > > Changes v4->v5:
> > > - Added pvrdma files to common UAPI folder.
> > > ---
> > > MAINTAINERS | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 87e23cd..5023dc0 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -12615,6 +12615,15 @@ S: Maintained
> > > F: drivers/scsi/vmw_pvscsi.c
> > > F: drivers/scsi/vmw_pvscsi.h
> > >
> > > +VMWARE PVRDMA DRIVER
> > > +M: Adit Ranadive <aditr@vmware.com>
> > > +M: VMware PV-Drivers <pv-drivers@vmware.com>
> > > +L: linux-rdma@vger.kernel.org
> > > +S: Maintained
> > > +F: drivers/infiniband/hw/pvrdma/
> > > +F: include/uapi/rdma/pvrdma-abi.h
> > > +F: include/uapi/rdma/pvrdma-uapi.h
> >
> > Please remove the last two lines, these files will be maintained by
> > Doug.
> >
> > Thanks
> >
>
> Ok. Based on your recent patch series on export vendor specific ABIs,
> the ABI files were added to be maintained [1] by individual driver owners.
> Is that not the case now?
I based my answer on this response from Doug [1], maybe I'm wrong.
[1] http://marc.info/?l=linux-rdma&m=147464894811998&w=2
>
> [1] http://marc.info/?l=linux-rdma&m=147455473718235&w=2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver
From: Leon Romanovsky @ 2016-09-26 5:57 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford, linux-rdma, pv-drivers, netdev, linux-pci, jhansen,
asarwade, georgezhang, bryantan
In-Reply-To: <9f65ab5c-d8c2-e8e3-9334-5d1865a20dc9@vmware.com>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Sun, Sep 25, 2016 at 10:25:12PM -0700, Adit Ranadive wrote:
> On Sun, Sep 25 2016 at 10:03:52AM +0300, Leon Romanovsky wrote:
> > On Sat, Sep 24, 2016 at 04:21:24PM -0700, Adit Ranadive wrote:
> >
> > <...>
> >
> > > include/uapi/rdma/pvrdma-abi.h | 99 ++
> > > include/uapi/rdma/pvrdma-uapi.h | 255 +++++
> >
> > As Jason said, you need a very good reason to split and create number of
> > files per-driver in UAPI folder.
>
> I can move the pvrdma-uapi.h back to the pvrdma driver folder.
Yes, please.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net/sched: pkt_cls: change tc actions order to be as the user sets
From: Hadar Hen Zion @ 2016-09-26 6:02 UTC (permalink / raw)
To: Cong Wang
Cc: Jamal Hadi Salim, Hadar Hen Zion, David S. Miller,
Linux Kernel Network Developers, Or Gerlitz
In-Reply-To: <CAM_iQpVBhckM4f43T0Lc2Bt28nVFBAjORHt5d=1_m9AfoPJtSg@mail.gmail.com>
On Mon, Sep 26, 2016 at 7:31 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Sun, Sep 25, 2016 at 7:39 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> On 16-09-25 10:08 AM, Hadar Hen Zion wrote:
>>>
>>> Currently the created tc actions list is reversed against the order
>>> set by the user.
>>> Change the actions list order to be the same as was set by the user.
>>>
>>
>>
>> Did something break? It seems to matter most for dumping. But even that
>> didnt breaking. Looking at the latest net tree, i tried:
>>
>
> The reason is we use action->order as an nested attribute, so
> the order in the list doesn't matter, only action->order itself matters.
The order in the list matters for offload drivers who use the
"tcf_exts_to_list" function and action->order parameter isn't usable
for them.
Why not keeping the actions in the same order as the user? isn't it
more elegant?
Hadar
>
> See tcf_action_dump():
>
> nest = nla_nest_start(skb, a->order);
^ permalink raw reply
* Re: [PATCH v5 13/16] IB/pvrdma: Add the main driver module for PVRDMA
From: Leon Romanovsky @ 2016-09-26 6:03 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <da4a09fc-bef1-60ea-f9af-7c505a9af6d6-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3500 bytes --]
On Sun, Sep 25, 2016 at 10:10:43PM -0700, Adit Ranadive wrote:
> On sun, Sep 25 2016 at 10:57:03AM +0300, Leon Romanovsky wrote:
> > On Sat, Sep 24, 2016 at 04:21:37PM -0700, Adit Ranadive wrote:
> > > This patch adds the support to register a RDMA device with the kernel RDMA
> > > stack as well as a kernel module. This also initializes the underlying
> > > virtual PCI device.
> > >
> > > Reviewed-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> > > Reviewed-by: Jorgen Hansen <jhansen-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > > Reviewed-by: George Zhang <georgezhang-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > > Reviewed-by: Aditya Sarwade <asarwade-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > > Reviewed-by: Bryan Tan <bryantan-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> > > Signed-off-by: Adit Ranadive <aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
>
> <...>
>
> > > +
> > > +#include <linux/errno.h>
> > > +#include <linux/inetdevice.h>
> > > +#include <linux/init.h>
> > > +#include <linux/module.h>
> > > +#include <linux/slab.h>
> > > +#include <rdma/ib_addr.h>
> > > +#include <rdma/ib_smi.h>
> > > +#include <rdma/ib_user_verbs.h>
> > > +#include <net/addrconf.h>
> > > +#include <rdma/pvrdma-abi.h>
> > > +
> > > +#include "pvrdma.h"
> > > +
> > > +#define DRV_NAME "pvrdma"
> > > +#define DRV_VERSION "1.0"
> > > +#define DRV_RELDATE "January 1, 2013"
> > > +
> > > +static const char pvrdma_version[] =
> > > + DRV_NAME ": PVRDMA InfiniBand driver v"
> > > + DRV_VERSION " (" DRV_RELDATE ")\n";
> >
> > This is a good example why driver version and reldate are useless in
> > kernel. We are in 2016 and not in 2013. All these data are forgotten to
> > update right after the developer copied it from other pre-historic driver
> > (very common practice in netdev). It is worth to stop to use this totally
> > useless defines.
> >
>
> Sorry, in our case it was the Mellanox mlx4 driver :). Yeah, I can remove
> DRV_VERSION and DRV_RELDATE. I'll keep the MODULE_VERSION since we keep
> track of our virtual driver versions that way. So when there are any changes
> to our driver we typically bump up the version. Not sure if that's a netdev
> or misc device practice and if thats followed here.
They always promise to do it, but after year or two they are stopping.
The funny thing starts when they start debug customer issues in specific
distro with mix of backported fixes/features from old and new kernels.
>
> <...>
>
> > > +static void pvrdma_get_fw_ver_str(struct ib_device *device, char *str,
> > > + size_t str_len)
> > > +{
> > > + struct pvrdma_dev *dev =
> > > + container_of(device, struct pvrdma_dev, ib_dev);
> > > + snprintf(str, str_len, "%d.%d.%d\n",
> > > + (int) (dev->dsr->caps.fw_ver >> 32),
> > > + (int) (dev->dsr->caps.fw_ver >> 16) & 0xffff,
> > > + (int) dev->dsr->caps.fw_ver & 0xffff);
> > > +}
> >
> > Yuval already pointed it to you.
> > Thanks to Ira, we have general function in core to print FW version.
> > Please use them.
> >
>
> If you are referring to commit 5fa76c20458518ed6181adddef2e31c5afc0745c
> then isnt this is exactly what Ira did for the other providers?
> Here, the pvrdma_get_fw_ver_str function is registered as a callback for
> the get_dev_fw_str API. Please our pvrdma_register_device function where
> we register our callbacks with ib_core:
> https://patchwork.kernel.org/patch/9349357/
>
> > > + dev->ib_dev.get_dev_fw_str = pvrdma_get_fw_ver_str;
You are right,
Sorry for that.
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 02/16] IB/pvrdma: Add user-level shared functions
From: Leon Romanovsky @ 2016-09-26 6:13 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford, linux-rdma, pv-drivers, netdev, linux-pci, jhansen,
asarwade, georgezhang, bryantan
In-Reply-To: <9c9f3668-ff2b-f421-2270-3193c0f62cc9@vmware.com>
[-- Attachment #1: Type: text/plain, Size: 9529 bytes --]
On Sun, Sep 25, 2016 at 09:22:11PM -0700, Adit Ranadive wrote:
> On Sun, Sep 25 2016 at 10:26:24AM +0300, Leon Romanovsky wrote:
> > > On Sat, Sep 24, 2016 at 04:21:26PM -0700, Adit Ranadive wrote:
> > > We share some common structures with the user-level driver. This patch adds
> > > those structures and shared functions to traverse the QP/CQ rings.
>
> <...>
>
> > > +
> > > +#include <linux/types.h>
> > > +
> > > +#define PVRDMA_UVERBS_ABI_VERSION 3
> > > +#define PVRDMA_BOARD_ID 1
> > > +#define PVRDMA_REV_ID 1
> > >
> > > Please don't add defines which you are not using in the library and the
> > > two above are not in use.
> > >
>
> I'll move these to the pvrdma.h file.
>
> <...>
>
> > > diff --git a/include/uapi/rdma/pvrdma-uapi.h b/include/uapi/rdma/pvrdma-uapi.h
> > > new file mode 100644
> > > index 0000000..430d8a5
>
> <...>
>
> > > +
> > > +#ifndef __PVRDMA_UAPI_H__
> > > +#define __PVRDMA_UAPI_H__
> > > +
> > > +#include <linux/types.h>
> > > +
> > > +#define PVRDMA_VERSION 17
> > >
> > > What do you plan to do with this VERSION?
> > > How is it related to ABI?
> > >
>
> Not related. This is only for the driver to know which APIs to support.
> For example, an older driver would still be able to work with a newer
> device. I can move this to pvrdma.h as well.
>
> To be honest, I thought I can move this file into the uapi folder since
> the structures here are shared with the user-level library. Based on
> your comments in this thread and the other ones, I think it makes sense
> to move this file back to the pvrdma driver folder and rename it
> (pvrdma_wqe.h?) to avoid confusion. There might still be some duplicate
> code (especially the UAR offsets and WQE structs) here and in our
> user-level library.
>
> Let me know if that makes sense.
>
> > > +
> > > +#define PVRDMA_UAR_HANDLE_MASK 0x00FFFFFF /* Bottom 24 bits. */
> > > +#define PVRDMA_UAR_QP_OFFSET 0 /* Offset of QP doorbell. */
> > > +#define PVRDMA_UAR_QP_SEND BIT(30) /* Send bit. */
> > > +#define PVRDMA_UAR_QP_RECV BIT(31) /* Recv bit. */
> > > +#define PVRDMA_UAR_CQ_OFFSET 4 /* Offset of CQ doorbell. */
> > > +#define PVRDMA_UAR_CQ_ARM_SOL BIT(29) /* Arm solicited bit. */
> > > +#define PVRDMA_UAR_CQ_ARM BIT(30) /* Arm bit. */
> > > +#define PVRDMA_UAR_CQ_POLL BIT(31) /* Poll bit. */
> > > +#define PVRDMA_INVALID_IDX -1 /* Invalid index. */
> > >
> > > +
> > > +/* PVRDMA atomic compare and swap */
> > > +struct pvrdma_exp_cmp_swap {
> > >
> > > _EXP_ looks very similar to MLNX_OFED naming convention.
> > >
>
> Yes, the operation was based on that. Any concerns?
> I can rename this and the one below.
Yes, please.
The common practice in IB subsystem is to use _ex_ notation for such
extended structures.
>
> > > + __u64 swap_val;
> > > + __u64 compare_val;
> > > + __u64 swap_mask;
> > > + __u64 compare_mask;
> > > +};
> > > +
> > > +/* PVRDMA atomic fetch and add */
> > > +struct pvrdma_exp_fetch_add {
> > >
> > > The same as above.
> > >
> > > + __u64 add_val;
> > > + __u64 field_boundary;
> > > +};
> > > +
> > > +/* PVRDMA address vector. */
> > > +struct pvrdma_av {
> > > + __u32 port_pd;
> > > + __u32 sl_tclass_flowlabel;
> > > + __u8 dgid[16];
> > > + __u8 src_path_bits;
> > > + __u8 gid_index;
> > > + __u8 stat_rate;
> > > + __u8 hop_limit;
> > > + __u8 dmac[6];
> > > + __u8 reserved[6];
> > > +};
> > > +
> > > +/* PVRDMA scatter/gather entry */
> > > +struct pvrdma_sge {
> > > + __u64 addr;
> > > + __u32 length;
> > > + __u32 lkey;
> > > +};
> > > +
> > > +/* PVRDMA receive queue work request */
> > > +struct pvrdma_rq_wqe_hdr {
> > > + __u64 wr_id; /* wr id */
> > > + __u32 num_sge; /* size of s/g array */
> > > + __u32 total_len; /* reserved */
> > > +};
> > > +/* Use pvrdma_sge (ib_sge) for receive queue s/g array elements. */
> > > +
> > > +/* PVRDMA send queue work request */
> > > +struct pvrdma_sq_wqe_hdr {
> > > + __u64 wr_id; /* wr id */
> > > + __u32 num_sge; /* size of s/g array */
> > > + __u32 total_len; /* reserved */
> > > + __u32 opcode; /* operation type */
> > > + __u32 send_flags; /* wr flags */
> > > + union {
> > > + __u32 imm_data;
> > > + __u32 invalidate_rkey;
> > > + } ex;
> > > + __u32 reserved;
> > > + union {
> > > + struct {
> > > + __u64 remote_addr;
> > > + __u32 rkey;
> > > + __u8 reserved[4];
> > > + } rdma;
> > > + struct {
> > > + __u64 remote_addr;
> > > + __u64 compare_add;
> > > + __u64 swap;
> > > + __u32 rkey;
> > > + __u32 reserved;
> > > + } atomic;
> > > + struct {
> > > + __u64 remote_addr;
> > > + __u32 log_arg_sz;
> > > + __u32 rkey;
> > > + union {
> > > + struct pvrdma_exp_cmp_swap cmp_swap;
> > > + struct pvrdma_exp_fetch_add fetch_add;
> > > + } wr_data;
> > > + } masked_atomics;
> > > + struct {
> > > + __u64 iova_start;
> > > + __u64 pl_pdir_dma;
> > > + __u32 page_shift;
> > > + __u32 page_list_len;
> > > + __u32 length;
> > > + __u32 access_flags;
> > > + __u32 rkey;
> > > + } fast_reg;
> > > + struct {
> > > + __u32 remote_qpn;
> > > + __u32 remote_qkey;
> > > + struct pvrdma_av av;
> > > + } ud;
> > > + } wr;
> > > +};
> > >
> > > No, I have half-baked patch series which refactors this structure in kernel.
> > > There is no need to put this structure in UAPI.
> > >
>
> This is specific to our device.. We do need to enqueue the WQE in this format
> for the device to recognize it. This is the same format that the user-level
> library will put the WQE in. As I said above, we can move this to the main
> pvrdma driver directory if you prefer.
This is different implementations between kernel and user space.
We don't want to bring user space limitations to kernel.
Take a look here:
http://lxr.free-electrons.com/source/include/rdma/ib_verbs.h#L1192
>
> > > +/* Use pvrdma_sge (ib_sge) for send queue s/g array elements. */
> > > +
> > > +/* Completion queue element. */
> > > +struct pvrdma_cqe {
> > > + __u64 wr_id;
> > > + __u64 qp;
> > > + __u32 opcode;
> > > + __u32 status;
> > > + __u32 byte_len;
> > > + __u32 imm_data;
> > > + __u32 src_qp;
> > > + __u32 wc_flags;
> > > + __u32 vendor_err;
> > > + __u16 pkey_index;
> > > + __u16 slid;
> > > + __u8 sl;
> > > + __u8 dlid_path_bits;
> > > + __u8 port_num;
> > > + __u8 smac[6];
> > > + __u8 reserved2[7]; /* Pad to next power of 2 (64). */
> > > +};
> > > +
> > > +struct pvrdma_ring {
> > > + atomic_t prod_tail; /* Producer tail. */
> > > + atomic_t cons_head; /* Consumer head. */
> > > +};
> > > +
> > > +struct pvrdma_ring_state {
> > > + struct pvrdma_ring tx; /* Tx ring. */
> > > + struct pvrdma_ring rx; /* Rx ring. */
> > > +};
> > > +
> > > +static inline int pvrdma_idx_valid(__u32 idx, __u32 max_elems)
> > > +{
> > > + /* Generates fewer instructions than a less-than. */
> > > + return (idx & ~((max_elems << 1) - 1)) == 0;
> > > +}
> > > +
> > > +static inline __s32 pvrdma_idx(atomic_t *var, __u32 max_elems)
> > > +{
> > > + const unsigned int idx = atomic_read(var);
> > > +
> > > + if (pvrdma_idx_valid(idx, max_elems))
> > > + return idx & (max_elems - 1);
> > > + return PVRDMA_INVALID_IDX;
> > > +}
> > > +
> > > +static inline void pvrdma_idx_ring_inc(atomic_t *var, __u32 max_elems)
> > > +{
> > > + __u32 idx = atomic_read(var) + 1; /* Increment. */
> > >
> > > It is definitely different atomic_read than you expect. From my grep
> > > searches on my machine, linux kernel doesn't export in standard headers
> > > the atomic_* functions and C has their implementation of that functions.
> > >
>
> This would probably change for the user-level library, so no need have this file
> in UAPI.
>
> > > +
> > > + idx &= (max_elems << 1) - 1; /* Modulo size, flip gen. */
> > > + atomic_set(var, idx);
> > > +}
> > > +
> > > +static inline __s32 pvrdma_idx_ring_has_space(const struct pvrdma_ring *r,
> > > + __u32 max_elems, __u32 *out_tail)
> > > +{
> > > + const __u32 tail = atomic_read(&r->prod_tail);
> > > + const __u32 head = atomic_read(&r->cons_head);
> > > +
> > > + if (pvrdma_idx_valid(tail, max_elems) &&
> > > + pvrdma_idx_valid(head, max_elems)) {
> > > + *out_tail = tail & (max_elems - 1);
> > > + return tail != (head ^ max_elems);
> > > + }
> > > + return PVRDMA_INVALID_IDX;
> > > +}
> > > +
> > > +static inline __s32 pvrdma_idx_ring_has_data(const struct pvrdma_ring *r,
> > > + __u32 max_elems, __u32 *out_head)
> > > +{
> > > + const __u32 tail = atomic_read(&r->prod_tail);
> > > + const __u32 head = atomic_read(&r->cons_head);
> > > +
> > > + if (pvrdma_idx_valid(tail, max_elems) &&
> > > + pvrdma_idx_valid(head, max_elems)) {
> > > + *out_head = head & (max_elems - 1);
> > > + return tail != head;
> > > + }
> > > + return PVRDMA_INVALID_IDX;
> > > +}
> > > +
> > > +static inline bool pvrdma_idx_ring_is_valid_idx(const struct pvrdma_ring *r,
> > > + __u32 max_elems, __u32 *idx)
> > > +{
> > > + const __u32 tail = atomic_read(&r->prod_tail);
> > > + const __u32 head = atomic_read(&r->cons_head);
> > > +
> > > + if (pvrdma_idx_valid(tail, max_elems) &&
> > > + pvrdma_idx_valid(head, max_elems) &&
> > > + pvrdma_idx_valid(*idx, max_elems)) {
> > > + if (tail > head && (*idx < tail && *idx >= head))
> > > + return true;
> > > + else if (head > tail && (*idx >= head || *idx < tail))
> > > + return true;
> > > + }
> > > + return false;
> > > +}
> > > +
> > > +#endif /* __PVRDMA_UAPI_H__ */
> > >
> > > I suggest completely remove this file from UAPI headers folder.
> > >
>
> I can move this back to the pvrdma driver folder.
Yes, please.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: Giuseppe CAVALLARO @ 2016-09-26 6:17 UTC (permalink / raw)
To: André Roth, Martin Blumenstingl
Cc: Alexandre Torgue, Johnson Leung, netdev, linux-amlogic
In-Reply-To: <20160917232312.1e30d425@gmail.com>
Hello André
On 9/17/2016 11:23 PM, André Roth wrote:
>
> Hi all,
>
> I have an odroid c2 board which shows this issue. No data is
> transmitted or received after a moment of intense tx traffic. Copying a
> 1GB file per scp from the board triggers it repeatedly.
>
> The board has a stmmac - user ID: 0x11, Synopsys ID: 0x37.
>
> When switching the network to 100Mb/s the copying does
> not seam to trigger the issue.
>
> I've attached the ethtool statistics before and after the problem.
at first glance, it enters in EEE mode often in the ethtool.after.
On some platforms we met problems and it was necessary to disable the
feature. Maybe, you can start looking at if this is true on yours.
We will see to provide a clean subset of patches to switch-on/off it.
Peppe
>
> Thanks for your help,
>
> André
>
>
>
>> Hi Alexandre,
>>
>> On Mon, Sep 12, 2016 at 6:37 PM, Alexandre Torgue
>> <alexandre.torgue@st.com> wrote:
>>> Which Synopsys IP version do you use ?
>> found this in a dmesg log:
>> [ 1.504784] stmmac - user ID: 0x11, Synopsys ID: 0x37
>> [ 1.509785] Ring mode enabled
>> [ 1.512796] DMA HW capability register supported
>> [ 1.517286] Normal descriptors
>> [ 1.520565] RX Checksum Offload Engine supported
>> [ 1.525219] COE Type 2
>> [ 1.527638] TX Checksum insertion supported
>> [ 1.531862] Wake-Up On Lan supported
>> [ 1.535483] Enable RX Mitigation via HW Watchdog Timer
>> [ 1.543851] libphy: stmmac: probed
>> [ 1.544025] eth0: PHY ID 001cc916 at 0 IRQ POLL (stmmac-0:00)
>> active [ 1.550321] eth0: PHY ID 001cc916 at 7 IRQ POLL
>> (stmmac-0:07)
>>
>>>> Gbit ethernet on my device is provided by a Realtek RTL8211F RGMII
>>>> PHY. Similar issues were reported in #linux-amlogic by a user with
>>>> an Odroid C2 board (= similar hardware).
>>>>
>>>> The symptoms are:
>>>> Receiving data is plenty fast (I can max out my internet connection
>>>> easily, and with iperf3 I get ~900Mbit/s).
>>>> Transmitting data from the device is unfortunately very slow,
>>>> traffic sometimes even stalls completely.
>>>>
>>>> I have attached the iperf results and the output of
>>>> /sys/kernel/debug/stmmaceth/eth0/descriptors_status.
>>>> Below you can find the ifconfig, netstat and stmmac dma_cap info
>>>> (*after* I ran all tests).
>>>>
>>>> The "involved parties" are:
>>>> - Meson GXBB specific network configuration registers (I have have
>>>> double-checked them with the reference drivers: everything seems
>>>> fine here)
>>>> - stmmac: it seems that nobody else has reported these kind of
>>>> issues so far, however I'd still like to hear where I should
>>>> enable some debugging bits to rule out any stmmac bug
>>>
>>>
>>> On my side, I just tested on the same "kind" of system:
>>> -SYNOPSYS GMAC 3.7
>>> -RTL8211EG as PHY
>>>
>>> With I perf, I reach:
>>> -RX: 932 Mbps
>>> -TX: 820Mbps
>>>
>>> Can you check ethtool -S eth0 (most precisely "MMC"counter and
>>> errors) ? Which kernel version do you use ?
>> I am using a 4.8.0-rc4 kernel, based on Kevin's "integration" branch:
>> [0] Unfortunately I don't have access to my device in the next few
>> days, but I'll keep you updated once I have the ethtool output.
>>
>>
>> Thanks for your time
>> Regards,
>> Martin
>>
>>
>> [0]
>> https://git.kernel.org/cgit/linux/kernel/git/khilman/linux-amlogic.git/log/?h=v4.8/integ
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>
>
^ permalink raw reply
* Re: [PATCH] net: hns: mark symbols static where possible
From: David Miller @ 2016-09-26 6:24 UTC (permalink / raw)
To: baoyou.xie
Cc: yisen.zhuang, salil.mehta, yankejian, huangdaode, lisheng011,
lipeng321, xieqianqian, weiyongjun1, oulijun, geliangtang,
simon.horman, vinod.koul, arnd, tremyfr, andrew, chenny.xu,
netdev, linux-kernel, xie.baoyou, han.fei, tang.qiang007
In-Reply-To: <1474796046-26370-1-git-send-email-baoyou.xie@linaro.org>
From: Baoyou Xie <baoyou.xie@linaro.org>
Date: Sun, 25 Sep 2016 17:34:06 +0800
> We get a few warnings when building kernel with W=1:
Patch does not apply to net-next.
^ permalink raw reply
* Re: [PATCH] net: mvneta: mark symbols static where possible
From: David Miller @ 2016-09-26 6:24 UTC (permalink / raw)
To: baoyou.xie
Cc: thomas.petazzoni, netdev, linux-kernel, arnd, xie.baoyou, han.fei,
tang.qiang007
In-Reply-To: <1474795241-23365-1-git-send-email-baoyou.xie@linaro.org>
From: Baoyou Xie <baoyou.xie@linaro.org>
Date: Sun, 25 Sep 2016 17:20:41 +0800
> We get 2 warnings when building kernel with W=1:
> drivers/net/ethernet/marvell/mvneta.c:639:27: warning: no previous prototype for 'mvneta_get_stats64' [-Wmissing-prototypes]
> drivers/net/ethernet/marvell/mvneta.c:3529:5: warning: no previous prototype for 'mvneta_ethtool_set_link_ksettings' [-Wmissing-prototypes]
>
> In fact, these two functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: hip04: mark tx_done() static
From: David Miller @ 2016-09-26 6:24 UTC (permalink / raw)
To: baoyou.xie
Cc: yisen.zhuang, salil.mehta, netdev, linux-kernel, arnd, xie.baoyou,
han.fei, tang.qiang007
In-Reply-To: <1474795144-15983-1-git-send-email-baoyou.xie@linaro.org>
From: Baoyou Xie <baoyou.xie@linaro.org>
Date: Sun, 25 Sep 2016 17:19:04 +0800
> We get 1 warning when building kernel with W=1:
> drivers/net/ethernet/hisilicon/hip04_eth.c:603:22: warning: no previous prototype for 'tx_done' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> so this patch marks this function with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: hisilicon: mark symbols static where possible
From: David Miller @ 2016-09-26 6:24 UTC (permalink / raw)
To: baoyou.xie
Cc: yisen.zhuang, salil.mehta, netdev, linux-kernel, arnd, xie.baoyou,
han.fei, tang.qiang007
In-Reply-To: <1474795004-8743-1-git-send-email-baoyou.xie@linaro.org>
From: Baoyou Xie <baoyou.xie@linaro.org>
Date: Sun, 25 Sep 2016 17:16:44 +0800
> We get 2 warnings when building kernel with W=1:
> drivers/net/ethernet/hisilicon/hisi_femac.c:943:5: warning: no previous prototype for 'hisi_femac_drv_suspend' [-Wmissing-prototypes]
> drivers/net/ethernet/hisilicon/hisi_femac.c:960:5: warning: no previous prototype for 'hisi_femac_drv_resume' [-Wmissing-prototypes]
>
> In fact, these two functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Applied.
^ 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