* Re: [net-next PATCH V2 3/5] samples/bpf: add a README file to get users started
From: Jesper Dangaard Brouer @ 2016-04-27 6:30 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: brouer, netdev, linux-kbuild, bblanco, naveen.n.rao, borkmann
In-Reply-To: <20160426173105.GD42777@ast-mbp.thefacebook.com>
On Tue, 26 Apr 2016 10:31:06 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Tue, Apr 26, 2016 at 06:27:22PM +0200, Jesper Dangaard Brouer wrote:
> > +
> > +Manually compiling LLVM with 'bpf' support
> > +------------------------------------------
> > +
> > +In some LLVM versions the BPF target were marked experimental. They
> > +needed the 'cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF'. Since
> > +version 3.7.1, LLVM adds a proper LLVM backend target for the BPF
> > +bytecode architecture.
>
> it's actually non-experimental since 3.7.0.
> It was experimental after 3.6 was released during development of 3.7.
> I doubt you can find this anywhere, so I suggest to just drop this paragraph.
Okay lets drop this paragraph, given the LLVM period was so short, it
does not make sense to mention here.
I will send a V3 patch series, as DaveM usually likes a full resubmit
(I'll add your acks to the other patches, but you need to ack this one).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] net/mlx4: Avoid wrong virtual mappings
From: Leon Romanovsky @ 2016-04-27 6:32 UTC (permalink / raw)
To: Haggai Abramovsky
Cc: David S. Miller, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Sinan Kaya, Timur Tabi, Eli Cohen,
Or Gerlitz, Eran Ben Elisha, Yishai Hadas, Tal Alon,
Saeed Mahameed
In-Reply-To: <1461591287-11595-1-git-send-email-hagaya-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
On Mon, Apr 25, 2016 at 04:34:47PM +0300, Haggai Abramovsky wrote:
> -int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
> - struct mlx4_buf *buf, gfp_t gfp)
> +static int mlx4_buf_direct_alloc(struct mlx4_dev *dev, int size,
> + struct mlx4_buf *buf, gfp_t gfp)
> {
> - dma_addr_t t;
> + dma_addr_t t;
>
You have wrong indentation in whole this function.
> - if (size <= max_direct) {
> buf->nbufs = 1;
> buf->npages = 1;
> buf->page_shift = get_order(size) + PAGE_SHIFT;
> - buf->direct.buf = dma_alloc_coherent(&dev->persist->pdev->dev,
> - size, &t, gfp);
> + buf->direct.buf =
> + dma_zalloc_coherent(&dev->persist->pdev->dev,
> + size, &t, gfp);
> if (!buf->direct.buf)
> return -ENOMEM;
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* (unknown)
From: Leon Romanovsky @ 2016-04-27 6:38 UTC (permalink / raw)
To: Florian Westphal
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
FaisalLatif-2ukJVAZIZ/Y
[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]
<faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Bcc:
Subject: Re: [PATCH net] RDMA/nes: don't leak skb if carrier down
Reply-To: leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <1461529139-28582-1-git-send-email-fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>
On Sun, Apr 24, 2016 at 10:18:59PM +0200, Florian Westphal wrote:
> Alternatively one could free the skb, OTOH I don't think this test is
> useful so just remove it.
>
> Cc: <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Signed-off-by: Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>
I don't know why did you decide to send it to netdev and not to relevant
maintainers, but the relevant mailing list is linux-rdma and Faisal
needs to Review/Acknowledge it.
➜ linux-rdma git:(master) ./scripts/get_maintainer.pl -f
drivers/infiniband/hw/nes/nes_nic.c
Faisal Latif <faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (supporter:NETEFFECT IWARP RNIC
DRIVER (IW_NES))
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (supporter:INFINIBAND SUBSYSTEM)
Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (supporter:INFINIBAND SUBSYSTEM)
Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (supporter:INFINIBAND
SUBSYSTEM)
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:NETEFFECT IWARP RNIC DRIVER
(IW_NES))
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list)
> ---
> Noticed this while working on the TX_LOCKED removal.
>
> diff --git a/drivers/infiniband/hw/nes/nes_nic.c b/drivers/infiniband/hw/nes/nes_nic.c
> index 3ea9e05..9291453 100644
> --- a/drivers/infiniband/hw/nes/nes_nic.c
> +++ b/drivers/infiniband/hw/nes/nes_nic.c
> @@ -500,9 +500,6 @@ static int nes_netdev_start_xmit(struct sk_buff *skb, struct net_device *netdev)
> * skb_shinfo(skb)->nr_frags, skb_is_gso(skb));
> */
>
> - if (!netif_carrier_ok(netdev))
> - return NETDEV_TX_OK;
> -
> if (netif_queue_stopped(netdev))
> return NETDEV_TX_BUSY;
>
> --
> 2.7.3
>
> --
> 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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next PATCH V2 5/5] samples/bpf: like LLC also verify and allow redefining CLANG command
From: Jesper Dangaard Brouer @ 2016-04-27 6:45 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: brouer, netdev, linux-kbuild, bblanco, naveen.n.rao, borkmann
In-Reply-To: <20160426173608.GF42777@ast-mbp.thefacebook.com>
On Tue, 26 Apr 2016 10:36:10 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Tue, Apr 26, 2016 at 06:27:32PM +0200, Jesper Dangaard Brouer wrote:
> > Users are likely to manually compile both LLVM 'llc' and 'clang'
> > tools. Thus, also allow redefining CLANG and verify command exist.
> >
> > Makefile implementation wise, the target that verify the command have
> > been generalized.
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
> > samples/bpf/Makefile | 23 +++++++++++++----------
> > samples/bpf/README.rst | 6 +++---
> > 2 files changed, 16 insertions(+), 13 deletions(-)
> >
> > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> > index dd63521832d8..c02ea9d2a248 100644
> > --- a/samples/bpf/Makefile
> > +++ b/samples/bpf/Makefile
> > @@ -81,9 +81,10 @@ HOSTLOADLIBES_spintest += -lelf
> > HOSTLOADLIBES_map_perf_test += -lelf -lrt
> > HOSTLOADLIBES_test_overhead += -lelf -lrt
> >
> > -# Allows pointing LLC to a LLVM backend with bpf support, redefine on cmdline:
> > -# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> > +# Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
> > +# make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> > LLC ?= llc
> > +CLANG ?= clang
> >
> > # Trick to allow make to be run from this directory
> > all:
> > @@ -94,15 +95,17 @@ clean:
> > @rm -f *~
> >
> > # Verify LLVM compiler is available and bpf target is supported
> > -.PHONY: verify_cmd_llc verify_target_bpf
> > +.PHONY: verify_cmd_llc verify_target_bpf $(CLANG) $(LLC)
> >
> > -verify_cmd_llc:
> > - @if ! (which "${LLC}" > /dev/null 2>&1); then \
> > - echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
> > - exit 1; \
> > - else true; fi
> > +verify_cmds: $(CLANG) $(LLC)
> > + @for TOOL in $^ ; do \
> > + if ! (which "$${TOOL}" > /dev/null 2>&1); then \
> > + echo "*** ERROR: Cannot find LLVM tool $${TOOL}" ;\
> > + exit 1; \
> > + else true; fi; \
> > + done
> >
> > -verify_target_bpf: verify_cmd_llc
> > +verify_target_bpf: verify_cmds
> > @if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
> > echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
> > echo " NOTICE: LLVM version >= 3.7.1 required" ;\
>
> If I read the patch correctly, it only checks that any version
> of clang is available and llc supports -march=bpf.
> That's correct.
Yes, you read the patch correctly :-)
> There is no need to build the latest clang most of the time.
> clang 3.4 and 3.5 are fine to compile samples/bpf/
> since llvm ir is mostly compatible with llc from 3.7 or 3.8
Good to get confirmation. I was testing with clang 3.5.0, and llc 3.9-git.
> Acked-by: Alexei Starovoitov <ast@kernel.org>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] net/mlx4: Avoid wrong virtual mappings
From: Haggai Abramovsky @ 2016-04-27 7:06 UTC (permalink / raw)
To: leon
Cc: Haggai Abramovsky, David S. Miller, Doug Ledford, linux-rdma,
netdev, Sinan Kaya, Timur Tabi, Eli Cohen, Or Gerlitz,
Eran Ben Elisha, Yishai Hadas, Tal Alon, Saeed Mahameed
In-Reply-To: <20160427063254.GM7974@leon.nu>
On Wed, Apr 27, 2016 at 9:32 AM, Leon Romanovsky <leon@kernel.org> wrote:
> On Mon, Apr 25, 2016 at 04:34:47PM +0300, Haggai Abramovsky wrote:
>> -int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
>> - struct mlx4_buf *buf, gfp_t gfp)
>> +static int mlx4_buf_direct_alloc(struct mlx4_dev *dev, int size,
>> + struct mlx4_buf *buf, gfp_t gfp)
>> {
>> - dma_addr_t t;
>> + dma_addr_t t;
>>
>
> You have wrong indentation in whole this function.
Thanks, I will fix this and send v1.
>
>> - if (size <= max_direct) {
>> buf->nbufs = 1;
>> buf->npages = 1;
>> buf->page_shift = get_order(size) + PAGE_SHIFT;
>> - buf->direct.buf = dma_alloc_coherent(&dev->persist->pdev->dev,
>> - size, &t, gfp);
>> + buf->direct.buf =
>> + dma_zalloc_coherent(&dev->persist->pdev->dev,
>> + size, &t, gfp);
>> if (!buf->direct.buf)
>> return -ENOMEM;
^ permalink raw reply
* [PATCH v1 net] net/mlx4: Avoid wrong virtual mappings
From: Haggai Abramovsky @ 2016-04-27 7:07 UTC (permalink / raw)
To: David S. Miller, Doug Ledford
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Sinan Kaya, Timur Tabi, Eli Cohen, Or Gerlitz, Eran Ben Elisha,
Yishai Hadas, Tal Alon, Saeed Mahameed, Haggai Abramovsky
The dma_alloc_coherent() function returns a virtual address which can
be used for coherent access to the underlying memory. On some
architectures, like arm64, undefined behavior results if this memory is
also accessed via virtual mappings that are not coherent. Because of
their undefined nature, operations like virt_to_page() return garbage
when passed virtual addresses obtained from dma_alloc_coherent(). Any
subsequent mappings via vmap() of the garbage page values are unusable
and result in bad things like bus errors (synchronous aborts in ARM64
speak).
The mlx4 driver contains code that does the equivalent of:
vmap(virt_to_page(dma_alloc_coherent)), this results in an OOPs when the
device is opened.
Prevent Ethernet driver to run this problematic code by forcing it to
allocate contiguous memory. As for the Infiniband driver, at first we
are trying to allocate contiguous memory, but in case of failure roll
back to work with fragmented memory.
Signed-off-by: Haggai Abramovsky <hagaya-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reported-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Tested-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
Changes from v0:
Fix indentation error raised by LeonR
drivers/infiniband/hw/mlx4/qp.c | 26 +++++--
drivers/net/ethernet/mellanox/mlx4/alloc.c | 93 ++++++++++-------------
drivers/net/ethernet/mellanox/mlx4/en_cq.c | 9 +--
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 31 --------
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 11 +--
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 14 +---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 -
include/linux/mlx4/device.h | 4 +-
9 files changed, 67 insertions(+), 125 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index fd97534..842a6da 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -419,7 +419,8 @@ static int set_rq_size(struct mlx4_ib_dev *dev, struct ib_qp_cap *cap,
}
static int set_kernel_sq_size(struct mlx4_ib_dev *dev, struct ib_qp_cap *cap,
- enum mlx4_ib_qp_type type, struct mlx4_ib_qp *qp)
+ enum mlx4_ib_qp_type type, struct mlx4_ib_qp *qp,
+ int shrink_wqe)
{
int s;
@@ -477,7 +478,7 @@ static int set_kernel_sq_size(struct mlx4_ib_dev *dev, struct ib_qp_cap *cap,
* We set WQE size to at least 64 bytes, this way stamping
* invalidates each WQE.
*/
- if (dev->dev->caps.fw_ver >= MLX4_FW_VER_WQE_CTRL_NEC &&
+ if (shrink_wqe && dev->dev->caps.fw_ver >= MLX4_FW_VER_WQE_CTRL_NEC &&
qp->sq_signal_bits && BITS_PER_LONG == 64 &&
type != MLX4_IB_QPT_SMI && type != MLX4_IB_QPT_GSI &&
!(type & (MLX4_IB_QPT_PROXY_SMI_OWNER | MLX4_IB_QPT_PROXY_SMI |
@@ -642,6 +643,7 @@ static int create_qp_common(struct mlx4_ib_dev *dev, struct ib_pd *pd,
{
int qpn;
int err;
+ struct ib_qp_cap backup_cap;
struct mlx4_ib_sqp *sqp;
struct mlx4_ib_qp *qp;
enum mlx4_ib_qp_type qp_type = (enum mlx4_ib_qp_type) init_attr->qp_type;
@@ -775,7 +777,8 @@ static int create_qp_common(struct mlx4_ib_dev *dev, struct ib_pd *pd,
goto err;
}
- err = set_kernel_sq_size(dev, &init_attr->cap, qp_type, qp);
+ memcpy(&backup_cap, &init_attr->cap, sizeof(backup_cap));
+ err = set_kernel_sq_size(dev, &init_attr->cap, qp_type, qp, 1);
if (err)
goto err;
@@ -787,9 +790,20 @@ static int create_qp_common(struct mlx4_ib_dev *dev, struct ib_pd *pd,
*qp->db.db = 0;
}
- if (mlx4_buf_alloc(dev->dev, qp->buf_size, PAGE_SIZE * 2, &qp->buf, gfp)) {
- err = -ENOMEM;
- goto err_db;
+ if (mlx4_buf_alloc(dev->dev, qp->buf_size, qp->buf_size,
+ &qp->buf, gfp)) {
+ memcpy(&init_attr->cap, &backup_cap,
+ sizeof(backup_cap));
+ err = set_kernel_sq_size(dev, &init_attr->cap, qp_type,
+ qp, 0);
+ if (err)
+ goto err_db;
+
+ if (mlx4_buf_alloc(dev->dev, qp->buf_size,
+ PAGE_SIZE * 2, &qp->buf, gfp)) {
+ err = -ENOMEM;
+ goto err_db;
+ }
}
err = mlx4_mtt_init(dev->dev, qp->buf.npages, qp->buf.page_shift,
diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
index 0c51c69..249a458 100644
--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
@@ -576,41 +576,48 @@ out:
return res;
}
-/*
- * Handling for queue buffers -- we allocate a bunch of memory and
- * register it in a memory region at HCA virtual address 0. If the
- * requested size is > max_direct, we split the allocation into
- * multiple pages, so we don't require too much contiguous memory.
- */
-int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
- struct mlx4_buf *buf, gfp_t gfp)
+static int mlx4_buf_direct_alloc(struct mlx4_dev *dev, int size,
+ struct mlx4_buf *buf, gfp_t gfp)
{
dma_addr_t t;
- if (size <= max_direct) {
- buf->nbufs = 1;
- buf->npages = 1;
- buf->page_shift = get_order(size) + PAGE_SHIFT;
- buf->direct.buf = dma_alloc_coherent(&dev->persist->pdev->dev,
- size, &t, gfp);
- if (!buf->direct.buf)
- return -ENOMEM;
+ buf->nbufs = 1;
+ buf->npages = 1;
+ buf->page_shift = get_order(size) + PAGE_SHIFT;
+ buf->direct.buf =
+ dma_zalloc_coherent(&dev->persist->pdev->dev,
+ size, &t, gfp);
+ if (!buf->direct.buf)
+ return -ENOMEM;
- buf->direct.map = t;
+ buf->direct.map = t;
- while (t & ((1 << buf->page_shift) - 1)) {
- --buf->page_shift;
- buf->npages *= 2;
- }
+ while (t & ((1 << buf->page_shift) - 1)) {
+ --buf->page_shift;
+ buf->npages *= 2;
+ }
- memset(buf->direct.buf, 0, size);
+ return 0;
+}
+
+/* Handling for queue buffers -- we allocate a bunch of memory and
+ * register it in a memory region at HCA virtual address 0. If the
+ * requested size is > max_direct, we split the allocation into
+ * multiple pages, so we don't require too much contiguous memory.
+ */
+int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
+ struct mlx4_buf *buf, gfp_t gfp)
+{
+ if (size <= max_direct) {
+ return mlx4_buf_direct_alloc(dev, size, buf, gfp);
} else {
+ dma_addr_t t;
int i;
- buf->direct.buf = NULL;
- buf->nbufs = (size + PAGE_SIZE - 1) / PAGE_SIZE;
- buf->npages = buf->nbufs;
+ buf->direct.buf = NULL;
+ buf->nbufs = (size + PAGE_SIZE - 1) / PAGE_SIZE;
+ buf->npages = buf->nbufs;
buf->page_shift = PAGE_SHIFT;
buf->page_list = kcalloc(buf->nbufs, sizeof(*buf->page_list),
gfp);
@@ -619,28 +626,12 @@ int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
for (i = 0; i < buf->nbufs; ++i) {
buf->page_list[i].buf =
- dma_alloc_coherent(&dev->persist->pdev->dev,
- PAGE_SIZE,
- &t, gfp);
+ dma_zalloc_coherent(&dev->persist->pdev->dev,
+ PAGE_SIZE, &t, gfp);
if (!buf->page_list[i].buf)
goto err_free;
buf->page_list[i].map = t;
-
- memset(buf->page_list[i].buf, 0, PAGE_SIZE);
- }
-
- if (BITS_PER_LONG == 64) {
- struct page **pages;
- pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
- if (!pages)
- goto err_free;
- for (i = 0; i < buf->nbufs; ++i)
- pages[i] = virt_to_page(buf->page_list[i].buf);
- buf->direct.buf = vmap(pages, buf->nbufs, VM_MAP, PAGE_KERNEL);
- kfree(pages);
- if (!buf->direct.buf)
- goto err_free;
}
}
@@ -655,15 +646,11 @@ EXPORT_SYMBOL_GPL(mlx4_buf_alloc);
void mlx4_buf_free(struct mlx4_dev *dev, int size, struct mlx4_buf *buf)
{
- int i;
-
- if (buf->nbufs == 1)
+ if (buf->nbufs == 1) {
dma_free_coherent(&dev->persist->pdev->dev, size,
- buf->direct.buf,
- buf->direct.map);
- else {
- if (BITS_PER_LONG == 64)
- vunmap(buf->direct.buf);
+ buf->direct.buf, buf->direct.map);
+ } else {
+ int i;
for (i = 0; i < buf->nbufs; ++i)
if (buf->page_list[i].buf)
@@ -789,7 +776,7 @@ void mlx4_db_free(struct mlx4_dev *dev, struct mlx4_db *db)
EXPORT_SYMBOL_GPL(mlx4_db_free);
int mlx4_alloc_hwq_res(struct mlx4_dev *dev, struct mlx4_hwq_resources *wqres,
- int size, int max_direct)
+ int size)
{
int err;
@@ -799,7 +786,7 @@ int mlx4_alloc_hwq_res(struct mlx4_dev *dev, struct mlx4_hwq_resources *wqres,
*wqres->db.db = 0;
- err = mlx4_buf_alloc(dev, size, max_direct, &wqres->buf, GFP_KERNEL);
+ err = mlx4_buf_direct_alloc(dev, size, &wqres->buf, GFP_KERNEL);
if (err)
goto err_db;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_cq.c b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
index af975a2..132cea6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_cq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
@@ -73,22 +73,16 @@ int mlx4_en_create_cq(struct mlx4_en_priv *priv,
*/
set_dev_node(&mdev->dev->persist->pdev->dev, node);
err = mlx4_alloc_hwq_res(mdev->dev, &cq->wqres,
- cq->buf_size, 2 * PAGE_SIZE);
+ cq->buf_size);
set_dev_node(&mdev->dev->persist->pdev->dev, mdev->dev->numa_node);
if (err)
goto err_cq;
- err = mlx4_en_map_buffer(&cq->wqres.buf);
- if (err)
- goto err_res;
-
cq->buf = (struct mlx4_cqe *)cq->wqres.buf.direct.buf;
*pcq = cq;
return 0;
-err_res:
- mlx4_free_hwq_res(mdev->dev, &cq->wqres, cq->buf_size);
err_cq:
kfree(cq);
*pcq = NULL;
@@ -177,7 +171,6 @@ void mlx4_en_destroy_cq(struct mlx4_en_priv *priv, struct mlx4_en_cq **pcq)
struct mlx4_en_dev *mdev = priv->mdev;
struct mlx4_en_cq *cq = *pcq;
- mlx4_en_unmap_buffer(&cq->wqres.buf);
mlx4_free_hwq_res(mdev->dev, &cq->wqres, cq->buf_size);
if (mlx4_is_eq_vector_valid(mdev->dev, priv->port, cq->vector) &&
cq->is_tx == RX)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index b4b258c..5b19178 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2907,7 +2907,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
/* Allocate page for receive rings */
err = mlx4_alloc_hwq_res(mdev->dev, &priv->res,
- MLX4_EN_PAGE_SIZE, MLX4_EN_PAGE_SIZE);
+ MLX4_EN_PAGE_SIZE);
if (err) {
en_err(priv, "Failed to allocate page for rx qps\n");
goto out;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_resources.c b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
index 02e925d..a6b0db0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_resources.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
@@ -107,37 +107,6 @@ int mlx4_en_change_mcast_lb(struct mlx4_en_priv *priv, struct mlx4_qp *qp,
return ret;
}
-int mlx4_en_map_buffer(struct mlx4_buf *buf)
-{
- struct page **pages;
- int i;
-
- if (BITS_PER_LONG == 64 || buf->nbufs == 1)
- return 0;
-
- pages = kmalloc(sizeof *pages * buf->nbufs, GFP_KERNEL);
- if (!pages)
- return -ENOMEM;
-
- for (i = 0; i < buf->nbufs; ++i)
- pages[i] = virt_to_page(buf->page_list[i].buf);
-
- buf->direct.buf = vmap(pages, buf->nbufs, VM_MAP, PAGE_KERNEL);
- kfree(pages);
- if (!buf->direct.buf)
- return -ENOMEM;
-
- return 0;
-}
-
-void mlx4_en_unmap_buffer(struct mlx4_buf *buf)
-{
- if (BITS_PER_LONG == 64 || buf->nbufs == 1)
- return;
-
- vunmap(buf->direct.buf);
-}
-
void mlx4_en_sqp_event(struct mlx4_qp *qp, enum mlx4_event event)
{
return;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 7d25bc9..89775bb 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -394,17 +394,11 @@ int mlx4_en_create_rx_ring(struct mlx4_en_priv *priv,
/* Allocate HW buffers on provided NUMA node */
set_dev_node(&mdev->dev->persist->pdev->dev, node);
- err = mlx4_alloc_hwq_res(mdev->dev, &ring->wqres,
- ring->buf_size, 2 * PAGE_SIZE);
+ err = mlx4_alloc_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
set_dev_node(&mdev->dev->persist->pdev->dev, mdev->dev->numa_node);
if (err)
goto err_info;
- err = mlx4_en_map_buffer(&ring->wqres.buf);
- if (err) {
- en_err(priv, "Failed to map RX buffer\n");
- goto err_hwq;
- }
ring->buf = ring->wqres.buf.direct.buf;
ring->hwtstamp_rx_filter = priv->hwtstamp_config.rx_filter;
@@ -412,8 +406,6 @@ int mlx4_en_create_rx_ring(struct mlx4_en_priv *priv,
*pring = ring;
return 0;
-err_hwq:
- mlx4_free_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
err_info:
vfree(ring->rx_info);
ring->rx_info = NULL;
@@ -517,7 +509,6 @@ void mlx4_en_destroy_rx_ring(struct mlx4_en_priv *priv,
struct mlx4_en_dev *mdev = priv->mdev;
struct mlx4_en_rx_ring *ring = *pring;
- mlx4_en_unmap_buffer(&ring->wqres.buf);
mlx4_free_hwq_res(mdev->dev, &ring->wqres, size * stride + TXBB_SIZE);
vfree(ring->rx_info);
ring->rx_info = NULL;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index c0d7b72..b9ab646 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -93,20 +93,13 @@ int mlx4_en_create_tx_ring(struct mlx4_en_priv *priv,
/* Allocate HW buffers on provided NUMA node */
set_dev_node(&mdev->dev->persist->pdev->dev, node);
- err = mlx4_alloc_hwq_res(mdev->dev, &ring->wqres, ring->buf_size,
- 2 * PAGE_SIZE);
+ err = mlx4_alloc_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
set_dev_node(&mdev->dev->persist->pdev->dev, mdev->dev->numa_node);
if (err) {
en_err(priv, "Failed allocating hwq resources\n");
goto err_bounce;
}
- err = mlx4_en_map_buffer(&ring->wqres.buf);
- if (err) {
- en_err(priv, "Failed to map TX buffer\n");
- goto err_hwq_res;
- }
-
ring->buf = ring->wqres.buf.direct.buf;
en_dbg(DRV, priv, "Allocated TX ring (addr:%p) - buf:%p size:%d buf_size:%d dma:%llx\n",
@@ -117,7 +110,7 @@ int mlx4_en_create_tx_ring(struct mlx4_en_priv *priv,
MLX4_RESERVE_ETH_BF_QP);
if (err) {
en_err(priv, "failed reserving qp for TX ring\n");
- goto err_map;
+ goto err_hwq_res;
}
err = mlx4_qp_alloc(mdev->dev, ring->qpn, &ring->qp, GFP_KERNEL);
@@ -154,8 +147,6 @@ int mlx4_en_create_tx_ring(struct mlx4_en_priv *priv,
err_reserve:
mlx4_qp_release_range(mdev->dev, ring->qpn, 1);
-err_map:
- mlx4_en_unmap_buffer(&ring->wqres.buf);
err_hwq_res:
mlx4_free_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
err_bounce:
@@ -182,7 +173,6 @@ void mlx4_en_destroy_tx_ring(struct mlx4_en_priv *priv,
mlx4_qp_remove(mdev->dev, &ring->qp);
mlx4_qp_free(mdev->dev, &ring->qp);
mlx4_qp_release_range(priv->mdev->dev, ring->qpn, 1);
- mlx4_en_unmap_buffer(&ring->wqres.buf);
mlx4_free_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
kfree(ring->bounce_buf);
ring->bounce_buf = NULL;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index d12ab6a..a70e2d0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -671,8 +671,6 @@ void mlx4_en_fill_qp_context(struct mlx4_en_priv *priv, int size, int stride,
int is_tx, int rss, int qpn, int cqn, int user_prio,
struct mlx4_qp_context *context);
void mlx4_en_sqp_event(struct mlx4_qp *qp, enum mlx4_event event);
-int mlx4_en_map_buffer(struct mlx4_buf *buf);
-void mlx4_en_unmap_buffer(struct mlx4_buf *buf);
int mlx4_en_change_mcast_lb(struct mlx4_en_priv *priv, struct mlx4_qp *qp,
int loopback);
void mlx4_en_calc_rx_buf(struct net_device *dev);
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 8541a91..72da65f 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -1051,7 +1051,7 @@ int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
void mlx4_buf_free(struct mlx4_dev *dev, int size, struct mlx4_buf *buf);
static inline void *mlx4_buf_offset(struct mlx4_buf *buf, int offset)
{
- if (BITS_PER_LONG == 64 || buf->nbufs == 1)
+ if (buf->nbufs == 1)
return buf->direct.buf + offset;
else
return buf->page_list[offset >> PAGE_SHIFT].buf +
@@ -1091,7 +1091,7 @@ int mlx4_db_alloc(struct mlx4_dev *dev, struct mlx4_db *db, int order,
void mlx4_db_free(struct mlx4_dev *dev, struct mlx4_db *db);
int mlx4_alloc_hwq_res(struct mlx4_dev *dev, struct mlx4_hwq_resources *wqres,
- int size, int max_direct);
+ int size);
void mlx4_free_hwq_res(struct mlx4_dev *mdev, struct mlx4_hwq_resources *wqres,
int size);
--
1.8.3.1
--
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 related
* Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag
From: Nicolas Ferre @ 2016-04-27 7:15 UTC (permalink / raw)
To: Sergei Shtylyov, David Miller
Cc: linux-kernel, linux-arm-kernel, gregory.clement,
alexandre.belloni, netdev, andrew
In-Reply-To: <571FB305.4060304@cogentembedded.com>
Le 26/04/2016 20:27, Sergei Shtylyov a écrit :
> On 04/26/2016 08:17 PM, David Miller wrote:
>
>>> I plan to queue this patch through arm-soc for 4.7.
>>
>> Ok.
>
> How about this patch going thru your net-next repo instead?
> I'd like to keep the kernel bisectable... if my phylib/macb patches get merged
> earlier than this one, that board would be broken...
Sergei, David,
I don't think that there is a big risk for this board to be tested in
the meantime as it's not widely deployed yet.
And as I'm aware of the issue and basically maintaining this DT file, I
think that I'll be informed if people try an unlikely arrangement of
patches on this board.
So either way, I'm okay. But I do think it's not worth thinking too much
about this case.
Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH net] net/mlx4: Avoid wrong virtual mappings
From: Christoph Hellwig @ 2016-04-27 7:19 UTC (permalink / raw)
To: Haggai Abramovsky
Cc: David S. Miller, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Sinan Kaya, Timur Tabi, Eli Cohen,
Or Gerlitz, Eran Ben Elisha, Yishai Hadas, Tal Alon,
Saeed Mahameed
In-Reply-To: <1461591287-11595-1-git-send-email-hagaya-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Hi Haggai,
I've taken a very quick look because I'm a little too busy this week,
but I failed to grasp the patch, as it seems to do a few too many
things. E.g. the whole wqe_shrink thing doesn't correspond to anything
in the description.
How about you split it into easily understanable chunks?
Also now that you split the few places that actually split
the allocation into chunks to be handled special I think the whole
mlx4_buf abstraction should go away, as it just obsfucates
how different the different use cases are.
--
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 9/9] taskstats: use the libnl API to align nlattr on 64-bit
From: Nicolas Dichtel @ 2016-04-27 7:29 UTC (permalink / raw)
To: Balbir Singh, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: dev-yBygre7rU0TnMu66kgdUjQ,
steffen.klassert-opNxpl+3fjRBDgjK7y7TUQ,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
aar-bIcnvbaLZ9MEGnE8C9+IrQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
kuznet-v/Mj1YrvjDBInbfyfbPRSQ, jmorris-gx6/JNMH7DfYtjvyW6yDsg,
linux-wpan-u79uwXL29TY76Z2rM5mHXA, kaber-dcUjhNyLwpNeoWH0uzbU5w,
pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <57201287.80002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Le 27/04/2016 03:14, Balbir Singh a écrit :
>
>
> On 23/04/16 01:31, Nicolas Dichtel wrote:
>> Goal of this patch is to use the new libnl API to align netlink attribute
>> when needed.
>> The layout of the netlink message will be a bit different after the patch,
>> because the padattr (TASKSTATS_TYPE_STATS) will be inside the nested
>> attribute instead of before it.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> The layout will change/break user space -- I've not tested the patch though..
Sigh.
I quote David:
"All userspace components using netlink should always ignore attributes
they do not recognize in dumps.
This is one of the most basic principles of netlink"
Do you have some pointers so I can made some tests?
Regards,
Nicolas
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [net-next PATCH V3 0/5] samples/bpf: Improve user experience
From: Jesper Dangaard Brouer @ 2016-04-27 7:30 UTC (permalink / raw)
To: netdev
Cc: linux-kbuild, bblanco, Jesper Dangaard Brouer, naveen.n.rao,
borkmann, alexei.starovoitov
It is a steep learning curve getting started with using the eBPF
examples in samples/bpf/. There are several dependencies, and
specific versions of these dependencies. Invoking make in the correct
manor is also slightly obscure.
This patchset cleanup, document and hopefully improves the first time
user experience with the eBPF samples directory by auto-detecting
certain scenarios.
V3:
- Add Alexei's ACKs
- Remove README paragraph about LLVM experimental BPF target
as it only existed between LLVM version 3.6 to 3.7.
V2:
- Adjusted recommend minimum versions to 3.7.1
- Included clang build instructions
- New patch adding CLANG variable and validation of command
---
Jesper Dangaard Brouer (5):
samples/bpf: add back functionality to redefine LLC command
samples/bpf: Makefile verify LLVM compiler avail and bpf target is supported
samples/bpf: add a README file to get users started
samples/bpf: allow make to be run from samples/bpf/ directory
samples/bpf: like LLC also verify and allow redefining CLANG command
samples/bpf/Makefile | 37 ++++++++++++++++++++++-
samples/bpf/README.rst | 78 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 113 insertions(+), 2 deletions(-)
create mode 100644 samples/bpf/README.rst
^ permalink raw reply
* [net-next PATCH V3 1/5] samples/bpf: add back functionality to redefine LLC command
From: Jesper Dangaard Brouer @ 2016-04-27 7:30 UTC (permalink / raw)
To: netdev
Cc: linux-kbuild, bblanco, Jesper Dangaard Brouer, naveen.n.rao,
borkmann, alexei.starovoitov
In-Reply-To: <20160427072855.29959.70252.stgit@firesoul>
It is practical to be-able-to redefine the location of the LLVM
command 'llc', because not all distros have a LLVM version with bpf
target support. Thus, it is sometimes required to compile LLVM from
source, and sometimes it is not desired to overwrite the distros
default LLVM version.
This feature was removed with 128d1514be35 ("samples/bpf: Use llc in
PATH, rather than a hardcoded value").
Add this features back. Note that it is possible to redefine the LLC
on the make command like:
make samples/bpf/ LLC=~/git/llvm/build/bin/llc
Fixes: 128d1514be35 ("samples/bpf: Use llc in PATH, rather than a hardcoded value")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
samples/bpf/Makefile | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 744dd7a16144..5bae9536f100 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -81,10 +81,14 @@ HOSTLOADLIBES_spintest += -lelf
HOSTLOADLIBES_map_perf_test += -lelf -lrt
HOSTLOADLIBES_test_overhead += -lelf -lrt
+# Allows pointing LLC to a LLVM backend with bpf support, redefine on cmdline:
+# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+LLC ?= llc
+
# asm/sysreg.h - inline assembly used by it is incompatible with llvm.
# But, there is no easy way to fix it, so just exclude it since it is
# useless for BPF samples.
$(obj)/%.o: $(src)/%.c
clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
- -O2 -emit-llvm -c $< -o -| llc -march=bpf -filetype=obj -o $@
+ -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
^ permalink raw reply related
* [net-next PATCH V3 2/5] samples/bpf: Makefile verify LLVM compiler avail and bpf target is supported
From: Jesper Dangaard Brouer @ 2016-04-27 7:30 UTC (permalink / raw)
To: netdev
Cc: linux-kbuild, bblanco, Jesper Dangaard Brouer, naveen.n.rao,
borkmann, alexei.starovoitov
In-Reply-To: <20160427072855.29959.70252.stgit@firesoul>
Make compiling samples/bpf more user friendly, by detecting if LLVM
compiler tool 'llc' is available, and also detect if the 'bpf' target
is available in this version of LLVM.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
samples/bpf/Makefile | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 5bae9536f100..45859c99f573 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -85,6 +85,24 @@ HOSTLOADLIBES_test_overhead += -lelf -lrt
# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
LLC ?= llc
+# Verify LLVM compiler is available and bpf target is supported
+.PHONY: verify_cmd_llc verify_target_bpf
+
+verify_cmd_llc:
+ @if ! (which "${LLC}" > /dev/null 2>&1); then \
+ echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
+ exit 1; \
+ else true; fi
+
+verify_target_bpf: verify_cmd_llc
+ @if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
+ echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
+ echo " NOTICE: LLVM version >= 3.7.1 required" ;\
+ exit 2; \
+ else true; fi
+
+$(src)/*.c: verify_target_bpf
+
# asm/sysreg.h - inline assembly used by it is incompatible with llvm.
# But, there is no easy way to fix it, so just exclude it since it is
# useless for BPF samples.
^ permalink raw reply related
* [net-next PATCH V3 3/5] samples/bpf: add a README file to get users started
From: Jesper Dangaard Brouer @ 2016-04-27 7:30 UTC (permalink / raw)
To: netdev
Cc: linux-kbuild, bblanco, Jesper Dangaard Brouer, naveen.n.rao,
borkmann, alexei.starovoitov
In-Reply-To: <20160427072855.29959.70252.stgit@firesoul>
Getting started with using examples in samples/bpf/ is not
straightforward. There are several dependencies, and specific
versions of these dependencies.
Just compiling the example tool is also slightly obscure, e.g. one
need to call make like:
make samples/bpf/
Do notice the "/" slash after the directory name.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/README.rst | 75 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
create mode 100644 samples/bpf/README.rst
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
new file mode 100644
index 000000000000..1fa157db905b
--- /dev/null
+++ b/samples/bpf/README.rst
@@ -0,0 +1,75 @@
+eBPF sample programs
+====================
+
+This kernel samples/bpf directory contains a mini eBPF library, test
+stubs, verifier test-suite and examples for using eBPF.
+
+Build dependencies
+==================
+
+Compiling requires having installed:
+ * clang >= version 3.4.0
+ * llvm >= version 3.7.1
+
+Note that LLVM's tool 'llc' must support target 'bpf', list with command::
+
+ $ llc --version
+ LLVM (http://llvm.org/):
+ LLVM version 3.x.y
+ [...]
+ Host CPU: xxx
+
+ Registered Targets:
+ [...]
+ bpf - BPF (host endian)
+ bpfeb - BPF (big endian)
+ bpfel - BPF (little endian)
+ [...]
+
+Kernel headers
+--------------
+
+There are usually dependencies to header files of the current kernel.
+To avoid installing devel kernel headers system wide, as a normal
+user, simply call::
+
+ make headers_install
+
+This will creates a local "usr/include" directory in the git/build top
+level directory, that the make system automatically pickup first.
+
+Compiling
+=========
+
+For compiling goto kernel top level build directory and run make like::
+
+ make samples/bpf/
+
+Do notice the "/" slash after the directory name.
+
+Manually compiling LLVM with 'bpf' support
+------------------------------------------
+
+Since version 3.7.0, LLVM adds a proper LLVM backend target for the
+BPF bytecode architecture.
+
+By default llvm will build all non-experimental backends including bpf.
+To generate a smaller llc binary one can use::
+
+ -DLLVM_TARGETS_TO_BUILD="BPF;X86"
+
+Quick sniplet for manually compiling LLVM and clang
+(build dependencies are cmake and gcc-c++)::
+
+ $ git clone http://llvm.org/git/llvm.git
+ $ cd llvm/tools
+ $ git clone --depth 1 http://llvm.org/git/clang.git
+ $ cd ..; mkdir build; cd build
+ $ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86"
+ $ make -j $(getconf _NPROCESSORS_ONLN)
+
+It is also possible to point make to the newly compiled 'llc' command
+via redefining LLC on the make command line::
+
+ make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+
^ permalink raw reply related
* [net-next PATCH V3 4/5] samples/bpf: allow make to be run from samples/bpf/ directory
From: Jesper Dangaard Brouer @ 2016-04-27 7:30 UTC (permalink / raw)
To: netdev
Cc: linux-kbuild, bblanco, Jesper Dangaard Brouer, naveen.n.rao,
borkmann, alexei.starovoitov
In-Reply-To: <20160427072855.29959.70252.stgit@firesoul>
It is not intuitive that 'make' must be run from the top level
directory with argument "samples/bpf/" to compile these eBPF samples.
Introduce a kbuild make file trick that allow make to be run from the
"samples/bpf/" directory itself. It basically change to the top level
directory and call "make samples/bpf/" with the "/" slash after the
directory name.
Also add a clean target that only cleans this directory, by taking
advantage of the kbuild external module setting M=$PWD.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
samples/bpf/Makefile | 8 ++++++++
samples/bpf/README.rst | 3 +++
2 files changed, 11 insertions(+)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 45859c99f573..dd63521832d8 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -85,6 +85,14 @@ HOSTLOADLIBES_test_overhead += -lelf -lrt
# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
LLC ?= llc
+# Trick to allow make to be run from this directory
+all:
+ $(MAKE) -C ../../ $$PWD/
+
+clean:
+ $(MAKE) -C ../../ M=$$PWD clean
+ @rm -f *~
+
# Verify LLVM compiler is available and bpf target is supported
.PHONY: verify_cmd_llc verify_target_bpf
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
index 1fa157db905b..6bbc7958c305 100644
--- a/samples/bpf/README.rst
+++ b/samples/bpf/README.rst
@@ -47,6 +47,9 @@ For compiling goto kernel top level build directory and run make like::
Do notice the "/" slash after the directory name.
+It is also possible to call make from this directory. This will just
+hide the the invocation of make as above with the appended "/".
+
Manually compiling LLVM with 'bpf' support
------------------------------------------
^ permalink raw reply related
* [net-next PATCH V3 5/5] samples/bpf: like LLC also verify and allow redefining CLANG command
From: Jesper Dangaard Brouer @ 2016-04-27 7:30 UTC (permalink / raw)
To: netdev
Cc: linux-kbuild, bblanco, Jesper Dangaard Brouer, naveen.n.rao,
borkmann, alexei.starovoitov
In-Reply-To: <20160427072855.29959.70252.stgit@firesoul>
Users are likely to manually compile both LLVM 'llc' and 'clang'
tools. Thus, also allow redefining CLANG and verify command exist.
Makefile implementation wise, the target that verify the command have
been generalized.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
samples/bpf/Makefile | 25 ++++++++++++++-----------
samples/bpf/README.rst | 6 +++---
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index dd63521832d8..157d68d6eace 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -81,9 +81,10 @@ HOSTLOADLIBES_spintest += -lelf
HOSTLOADLIBES_map_perf_test += -lelf -lrt
HOSTLOADLIBES_test_overhead += -lelf -lrt
-# Allows pointing LLC to a LLVM backend with bpf support, redefine on cmdline:
-# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+# Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
+# make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
LLC ?= llc
+CLANG ?= clang
# Trick to allow make to be run from this directory
all:
@@ -93,16 +94,18 @@ clean:
$(MAKE) -C ../../ M=$$PWD clean
@rm -f *~
-# Verify LLVM compiler is available and bpf target is supported
-.PHONY: verify_cmd_llc verify_target_bpf
+# Verify LLVM compiler tools are available and bpf target is supported by llc
+.PHONY: verify_cmds verify_target_bpf $(CLANG) $(LLC)
-verify_cmd_llc:
- @if ! (which "${LLC}" > /dev/null 2>&1); then \
- echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
- exit 1; \
- else true; fi
+verify_cmds: $(CLANG) $(LLC)
+ @for TOOL in $^ ; do \
+ if ! (which "$${TOOL}" > /dev/null 2>&1); then \
+ echo "*** ERROR: Cannot find LLVM tool $${TOOL}" ;\
+ exit 1; \
+ else true; fi; \
+ done
-verify_target_bpf: verify_cmd_llc
+verify_target_bpf: verify_cmds
@if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
echo " NOTICE: LLVM version >= 3.7.1 required" ;\
@@ -115,6 +118,6 @@ $(src)/*.c: verify_target_bpf
# But, there is no easy way to fix it, so just exclude it since it is
# useless for BPF samples.
$(obj)/%.o: $(src)/%.c
- clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
+ $(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
index 6bbc7958c305..d653548467a5 100644
--- a/samples/bpf/README.rst
+++ b/samples/bpf/README.rst
@@ -71,8 +71,8 @@ Quick sniplet for manually compiling LLVM and clang
$ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86"
$ make -j $(getconf _NPROCESSORS_ONLN)
-It is also possible to point make to the newly compiled 'llc' command
-via redefining LLC on the make command line::
+It is also possible to point make to the newly compiled 'llc' or
+'clang' command via redefining LLC or CLANG on the make command line::
- make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+ make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
^ permalink raw reply related
* [PATCH v2 0/2] pegasus: correct buffer sizes
From: Petko Manolov @ 2016-04-27 7:35 UTC (permalink / raw)
To: netdev; +Cc: davem, a1291762, Petko Manolov
As noticed by Lincoln Ramsay <a1291762@gmail.com> some old (usb 1.1) Pegasus
based devices may actually return more bytes than the specified in the datasheet
amount. That would not be a problem if the allocated space for the SKB was
equal to the parameter passed to usb_fill_bulk_urb(). Some poor bugger (i
really hope it was not me, but 'git blame' is useless in this case, so anyway)
decided to add '+ 8' to the buffer length parameter. Sometimes the usb transfer
overflows and corrupts the socket structure, leading to kernel panic.
The above doesn't seem to happen for newer (Pegasus2 based) devices which did
help this bug to hide for so long.
Nearly all Pegasus devices may append the RX status to the end of the received
packet. It is the default setup for the driver. The actual ethernet packet is
4 bytes shorter. Why and when 'pkt_len -= 4' became 'pkt_len -= 8' is again
hidden in the mists of time. There might have been a good reason to do so, but
multiple reads of the datasheet did not point me to any.
The patch is against v4.6-rc5 and was tested on ADM8515 device by transferring
multiple gigabytes of data over a couple of days without any complaints from the
kernel.
Changes since v1:
- split the patch in two parts;
- corrected the subject lines;
Petko Manolov (2):
pegasus: fixes URB buffer allocation size;
pegasus: fixes reported packet length
drivers/net/usb/pegasus.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.8.0.rc3
^ permalink raw reply
* [PATCH v2 1/2] pegasus: fixes URB buffer allocation size;
From: Petko Manolov @ 2016-04-27 7:35 UTC (permalink / raw)
To: netdev; +Cc: davem, a1291762, Petko Manolov
In-Reply-To: <1461742525-2748-1-git-send-email-petkan@mip-labs.com>
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.
Reported-by: Lincoln Ramsay <a1291762@gmail.com>
Signed-off-by: Petko Manolov <petkan@mip-labs.com>
---
drivers/net/usb/pegasus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index f840802..f919e20 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -528,7 +528,7 @@ static void read_bulk_callback(struct urb *urb)
goon:
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
rx_status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
if (rx_status == -ENODEV)
@@ -569,7 +569,7 @@ static void rx_fixup(unsigned long data)
}
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
try_again:
status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
@@ -823,7 +823,7 @@ static int pegasus_open(struct net_device *net)
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
if ((res = usb_submit_urb(pegasus->rx_urb, GFP_KERNEL))) {
if (res == -ENODEV)
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH v2 2/2] pegasus: fixes reported packet length
From: Petko Manolov @ 2016-04-27 7:35 UTC (permalink / raw)
To: netdev; +Cc: davem, a1291762, Petko Manolov
In-Reply-To: <1461742525-2748-1-git-send-email-petkan@mip-labs.com>
According to ADM851x docs the ethernet packet is appended with 4
bytes, not 8. Fixing this to report (hopefully) the right amount
of data.
Signed-off-by: Petko Manolov <petkan@mip-labs.com>
---
drivers/net/usb/pegasus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index f919e20..780c217 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -497,7 +497,7 @@ static void read_bulk_callback(struct urb *urb)
pkt_len = buf[count - 3] << 8;
pkt_len += buf[count - 4];
pkt_len &= 0xfff;
- pkt_len -= 8;
+ pkt_len -= 4;
}
/*
--
2.8.0.rc3
^ permalink raw reply related
* Re: [PATCH v2 0/2] pegasus: correct buffer sizes
From: Johannes Berg @ 2016-04-27 7:46 UTC (permalink / raw)
To: Petko Manolov, netdev; +Cc: davem, a1291762
In-Reply-To: <1461742525-2748-1-git-send-email-petkan@mip-labs.com>
On Wed, 2016-04-27 at 10:35 +0300, Petko Manolov wrote:
>
> Nearly all Pegasus devices may append the RX status to the end of the
> received packet. It is the default setup for the driver. The
> actual ethernet packet is 4 bytes shorter. Why and when 'pkt_len -=
> 4' became 'pkt_len -= 8' is again hidden in the mists of time. There
> might have been a good reason to do so, but multiple reads of the
> datasheet did not point me to any.
>
Wild guess: (some) devices pass the FCS, perhaps depending on the
configuration?
johannes
^ permalink raw reply
* [patch] tipc: remove an unnecessary NULL check
From: Dan Carpenter @ 2016-04-27 8:05 UTC (permalink / raw)
To: Jon Maloy
Cc: Ying Xue, David S. Miller, netdev, tipc-discussion,
kernel-janitors
This is never called with a NULL "buf" and anyway, we dereference 's' on
the lines before so it would Oops before we reach the check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c
index 79de588..0dd0224 100644
--- a/net/tipc/subscr.c
+++ b/net/tipc/subscr.c
@@ -326,8 +326,7 @@ static void tipc_subscrb_rcv_cb(struct net *net, int conid,
return tipc_subscrp_cancel(s, subscriber);
}
- if (s)
- tipc_subscrp_subscribe(net, s, subscriber, swap);
+ tipc_subscrp_subscribe(net, s, subscriber, swap);
}
/* Handle one request to establish a new subscriber */
^ permalink raw reply related
* Re: [net-next PATCH V3 1/5] samples/bpf: add back functionality to redefine LLC command
From: Naveen N. Rao @ 2016-04-27 8:06 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, borkmann, alexei.starovoitov
In-Reply-To: <20160427073013.29959.86846.stgit@firesoul>
On 2016/04/27 09:30AM, Jesper Dangaard Brouer wrote:
> It is practical to be-able-to redefine the location of the LLVM
> command 'llc', because not all distros have a LLVM version with bpf
> target support. Thus, it is sometimes required to compile LLVM from
> source, and sometimes it is not desired to overwrite the distros
> default LLVM version.
>
> This feature was removed with 128d1514be35 ("samples/bpf: Use llc in
> PATH, rather than a hardcoded value").
>
> Add this features back. Note that it is possible to redefine the LLC
> on the make command like:
>
> make samples/bpf/ LLC=~/git/llvm/build/bin/llc
Why not do:
PATH=~/git/llvm/build/bin:$PATH make samples/bpf/
..if you wish to override clang/llc only for building bpf samples?
Or, just export the updated $PATH:
export PATH=~/git/llvm/build/bin:$PATH
make samples/bpf
- Naveen
^ permalink raw reply
* Re: [PATCH net] net/mlx4: Avoid wrong virtual mappings
From: Haggai Abramovsky @ 2016-04-27 8:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Haggai Abramovsky, David S. Miller, Doug Ledford,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Sinan Kaya, Timur Tabi, Eli Cohen, Or Gerlitz, Eran Ben Elisha,
Yishai Hadas, Tal Alon, Saeed Mahameed
In-Reply-To: <20160427071920.GA26712-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Wed, Apr 27, 2016 at 10:19 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> Hi Haggai,
>
> I've taken a very quick look because I'm a little too busy this week,
> but I failed to grasp the patch, as it seems to do a few too many
> things. E.g. the whole wqe_shrink thing doesn't correspond to anything
> in the description.
when creating QP from mlx4_ib kernel verbs, we decide if we are
going to work using shrinked wqe or regular wqe (not something i
added).
shrinked wqe means that WQE can be more than one WQE BB (basic block),
regular wqe - means that every WQE is exact one WQE BB,
> How about you split it into easily understanable chunks?
We had internal discussion about this issue.
we decided not to split the patch because it can break kernel
apps/ulps running over the infiniband driver.
e.g once we removing vmap and not adjust the infiniband driver to work
with fragmented memory,
we can fail when trying to allocate contiguous memory using
dma_zalloc_coherent() while succeeding if trying to allocate
fragmented memory.
> Also now that you split the few places that actually split
> the allocation into chunks to be handled special I think the whole
> mlx4_buf abstraction should go away, as it just obsfucates
> how different the different use cases are.
we still need this mlx4_buf abstraction to store the info on whether
we are working with fragmented memory (can be in IB driver) or direct
memory.
> --
> 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
--
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: [net-next PATCH V3 3/5] samples/bpf: add a README file to get users started
From: Naveen N. Rao @ 2016-04-27 8:35 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, borkmann, alexei.starovoitov
In-Reply-To: <20160427073023.29959.17816.stgit@firesoul>
On 2016/04/27 09:30AM, Jesper Dangaard Brouer wrote:
> Getting started with using examples in samples/bpf/ is not
> straightforward. There are several dependencies, and specific
> versions of these dependencies.
>
> Just compiling the example tool is also slightly obscure, e.g. one
> need to call make like:
>
> make samples/bpf/
>
> Do notice the "/" slash after the directory name.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> samples/bpf/README.rst | 75 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 75 insertions(+)
> create mode 100644 samples/bpf/README.rst
Thanks for adding this! A few nits...
>
> diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
> new file mode 100644
> index 000000000000..1fa157db905b
> --- /dev/null
> +++ b/samples/bpf/README.rst
> @@ -0,0 +1,75 @@
> +eBPF sample programs
> +====================
> +
> +This kernel samples/bpf directory contains a mini eBPF library, test
^^^^^^^^^^^^^^^^^^
'This directory contains' should suffice.
> +stubs, verifier test-suite and examples for using eBPF.
> +
> +Build dependencies
> +==================
> +
> +Compiling requires having installed:
> + * clang >= version 3.4.0
> + * llvm >= version 3.7.1
> +
> +Note that LLVM's tool 'llc' must support target 'bpf', list with command::
> +
> + $ llc --version
'llc --version | grep bpf' is probably simpler?
> + LLVM (http://llvm.org/):
> + LLVM version 3.x.y
> + [...]
> + Host CPU: xxx
> +
> + Registered Targets:
> + [...]
> + bpf - BPF (host endian)
> + bpfeb - BPF (big endian)
> + bpfel - BPF (little endian)
> + [...]
> +
> +Kernel headers
> +--------------
> +
> +There are usually dependencies to header files of the current kernel.
> +To avoid installing devel kernel headers system wide, as a normal
> +user, simply call::
> +
> + make headers_install
> +
> +This will creates a local "usr/include" directory in the git/build top
> +level directory, that the make system automatically pickup first.
> +
> +Compiling
> +=========
> +
> +For compiling goto kernel top level build directory and run make like::
For building the BPF samples, issue the below command from the kernel
root directory:
> +
> + make samples/bpf/
> +
> +Do notice the "/" slash after the directory name.
> +
> +Manually compiling LLVM with 'bpf' support
> +------------------------------------------
> +
> +Since version 3.7.0, LLVM adds a proper LLVM backend target for the
> +BPF bytecode architecture.
> +
> +By default llvm will build all non-experimental backends including bpf.
> +To generate a smaller llc binary one can use::
> +
> + -DLLVM_TARGETS_TO_BUILD="BPF;X86"
Is the X86 target really needed?
> +
> +Quick sniplet for manually compiling LLVM and clang
> +(build dependencies are cmake and gcc-c++)::
> +
> + $ git clone http://llvm.org/git/llvm.git
> + $ cd llvm/tools
> + $ git clone --depth 1 http://llvm.org/git/clang.git
> + $ cd ..; mkdir build; cd build
> + $ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86"
^^^
Here too.
- Naveen
> + $ make -j $(getconf _NPROCESSORS_ONLN)
> +
> +It is also possible to point make to the newly compiled 'llc' command
> +via redefining LLC on the make command line::
> +
> + make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> +
>
^ permalink raw reply
* Re: [net-next PATCH V3 2/5] samples/bpf: Makefile verify LLVM compiler avail and bpf target is supported
From: Naveen N. Rao @ 2016-04-27 8:54 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, borkmann, alexei.starovoitov
In-Reply-To: <20160427073018.29959.57913.stgit@firesoul>
On 2016/04/27 09:30AM, Jesper Dangaard Brouer wrote:
> Make compiling samples/bpf more user friendly, by detecting if LLVM
> compiler tool 'llc' is available, and also detect if the 'bpf' target
> is available in this version of LLVM.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
> samples/bpf/Makefile | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 5bae9536f100..45859c99f573 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -85,6 +85,24 @@ HOSTLOADLIBES_test_overhead += -lelf -lrt
> # make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> LLC ?= llc
>
> +# Verify LLVM compiler is available and bpf target is supported
> +.PHONY: verify_cmd_llc verify_target_bpf
> +
> +verify_cmd_llc:
> + @if ! (which "${LLC}" > /dev/null 2>&1); then \
> + echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
> + exit 1; \
> + else true; fi
> +
> +verify_target_bpf: verify_cmd_llc
> + @if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
> + echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
> + echo " NOTICE: LLVM version >= 3.7.1 required" ;\
> + exit 2; \
> + else true; fi
> +
> +$(src)/*.c: verify_target_bpf
> +
> # asm/sysreg.h - inline assembly used by it is incompatible with llvm.
> # But, there is no easy way to fix it, so just exclude it since it is
> # useless for BPF samples.
>
^ permalink raw reply
* Re: [PATCH net-next 1/1] pch_gbe: replace private tx ring lock with common netif_tx_lock
From: Nikolay Aleksandrov @ 2016-04-27 8:55 UTC (permalink / raw)
To: Francois Romieu, netdev; +Cc: davem
In-Reply-To: <20160426224921.GA29558@electric-eye.fr.zoreil.com>
On 04/27/2016 12:49 AM, Francois Romieu wrote:
> pch_gbe_tx_ring.tx_lock is only used in the hard_xmit handler and
> in the transmit completion reaper called from NAPI context.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> ---
> CONFIG_COMPILE_TESTed
>
> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 2 --
> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 10 ++--------
> 2 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
> index 2a55d6d..8d710a3 100644
> --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
> @@ -481,7 +481,6 @@ struct pch_gbe_buffer {
>
> /**
> * struct pch_gbe_tx_ring - tx ring information
> - * @tx_lock: spinlock structs
> * @desc: pointer to the descriptor ring memory
> * @dma: physical address of the descriptor ring
> * @size: length of descriptor ring in bytes
> @@ -491,7 +490,6 @@ struct pch_gbe_buffer {
> * @buffer_info: array of buffer information structs
> */
> struct pch_gbe_tx_ring {
> - spinlock_t tx_lock;
> struct pch_gbe_tx_desc *desc;
> dma_addr_t dma;
> unsigned int size;
> diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> index ca4add7..5c8e2f1 100644
> --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> @@ -1640,7 +1640,7 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
> cleaned_count);
> if (cleaned_count > 0) { /*skip this if nothing cleaned*/
> /* Recover from running out of Tx resources in xmit_frame */
> - spin_lock(&tx_ring->tx_lock);
> + netif_tx_lock(adapter->netdev);
> if (unlikely(cleaned && (netif_queue_stopped(adapter->netdev))))
> {
> netif_wake_queue(adapter->netdev);
> @@ -1652,7 +1652,7 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
>
> netdev_dbg(adapter->netdev, "next_to_clean : %d\n",
> tx_ring->next_to_clean);
> - spin_unlock(&tx_ring->tx_lock);
> + netif_tx_lock(adapter->netdev);
Shouldn't this be netif_tx_unlock ?
> }
> return cleaned;
> }
> @@ -1805,7 +1805,6 @@ int pch_gbe_setup_tx_resources(struct pch_gbe_adapter *adapter,
>
> tx_ring->next_to_use = 0;
> tx_ring->next_to_clean = 0;
> - spin_lock_init(&tx_ring->tx_lock);
>
> for (desNo = 0; desNo < tx_ring->count; desNo++) {
> tx_desc = PCH_GBE_TX_DESC(*tx_ring, desNo);
> @@ -2135,13 +2134,9 @@ static int pch_gbe_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> {
> struct pch_gbe_adapter *adapter = netdev_priv(netdev);
> struct pch_gbe_tx_ring *tx_ring = adapter->tx_ring;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&tx_ring->tx_lock, flags);
>
> if (unlikely(!PCH_GBE_DESC_UNUSED(tx_ring))) {
> netif_stop_queue(netdev);
> - spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
> netdev_dbg(netdev,
> "Return : BUSY next_to use : 0x%08x next_to clean : 0x%08x\n",
> tx_ring->next_to_use, tx_ring->next_to_clean);
> @@ -2150,7 +2145,6 @@ static int pch_gbe_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
>
> /* CRC,ITAG no support */
> pch_gbe_tx_queue(adapter, tx_ring, skb);
> - spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
> return NETDEV_TX_OK;
> }
>
>
^ 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