* [PATCH net 5/6] bnxt_en: Add software "missed_irqs" counter.
From: Michael Chan @ 2018-11-15 8:25 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1542270342-18361-1-git-send-email-michael.chan@broadcom.com>
To keep track of the number of times the workaround code for 57500 A0
has been triggered. This is a per NQ counter.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1 +
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 +
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 5 ++++-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 5d4147a..d4c3001 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8909,6 +8909,7 @@ static void bnxt_chk_missed_irq(struct bnxt *bp)
bnxt_dbg_hwrm_ring_info_get(bp,
DBG_RING_INFO_GET_REQ_RING_TYPE_L2_CMPL,
fw_ring_id, &val[0], &val[1]);
+ cpr->missed_irqs++;
}
}
}
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 00bd17e..9e99d4a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -818,6 +818,7 @@ struct bnxt_cp_ring_info {
dma_addr_t hw_stats_map;
u32 hw_stats_ctx_id;
u64 rx_l4_csum_errors;
+ u64 missed_irqs;
struct bnxt_ring_struct cp_ring_struct;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index 4807856..4b734cd 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -137,7 +137,7 @@ static int bnxt_set_coalesce(struct net_device *dev,
return rc;
}
-#define BNXT_NUM_STATS 21
+#define BNXT_NUM_STATS 22
#define BNXT_RX_STATS_ENTRY(counter) \
{ BNXT_RX_STATS_OFFSET(counter), __stringify(counter) }
@@ -384,6 +384,7 @@ static void bnxt_get_ethtool_stats(struct net_device *dev,
for (k = 0; k < stat_fields; j++, k++)
buf[j] = le64_to_cpu(hw_stats[k]);
buf[j++] = cpr->rx_l4_csum_errors;
+ buf[j++] = cpr->missed_irqs;
bnxt_sw_func_stats[RX_TOTAL_DISCARDS].counter +=
le64_to_cpu(cpr->hw_stats->rx_discard_pkts);
@@ -468,6 +469,8 @@ static void bnxt_get_strings(struct net_device *dev, u32 stringset, u8 *buf)
buf += ETH_GSTRING_LEN;
sprintf(buf, "[%d]: rx_l4_csum_errors", i);
buf += ETH_GSTRING_LEN;
+ sprintf(buf, "[%d]: missed_irqs", i);
+ buf += ETH_GSTRING_LEN;
}
for (i = 0; i < BNXT_NUM_SW_FUNC_STATS; i++) {
strcpy(buf, bnxt_sw_func_stats[i].string);
--
2.5.1
^ permalink raw reply related
* [PATCH net 6/6] bnxt_en: Fix filling time in bnxt_fill_coredump_record()
From: Michael Chan @ 2018-11-15 8:25 UTC (permalink / raw)
To: davem; +Cc: netdev, Vasundhara Volam
In-Reply-To: <1542270342-18361-1-git-send-email-michael.chan@broadcom.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Fix the year and month offset while storing it in
bnxt_fill_coredump_record().
Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index 4b734cd..6cc69a5 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -2945,8 +2945,8 @@ bnxt_fill_coredump_record(struct bnxt *bp, struct bnxt_coredump_record *record,
record->asic_state = 0;
strlcpy(record->system_name, utsname()->nodename,
sizeof(record->system_name));
- record->year = cpu_to_le16(tm.tm_year);
- record->month = cpu_to_le16(tm.tm_mon);
+ record->year = cpu_to_le16(tm.tm_year + 1900);
+ record->month = cpu_to_le16(tm.tm_mon + 1);
record->day = cpu_to_le16(tm.tm_mday);
record->hour = cpu_to_le16(tm.tm_hour);
record->minute = cpu_to_le16(tm.tm_min);
--
2.5.1
^ permalink raw reply related
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:27 UTC (permalink / raw)
To: Michael S. Tsirkin, jiangyiwen
Cc: stefanha, stefanha, netdev, kvm, virtualization
In-Reply-To: <20181115025622-mutt-send-email-mst@kernel.org>
On 2018/11/15 下午4:10, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
>> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
>>> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>>>> Hi Stefan, Michael, Jason and everyone,
>>>>
>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>> This idea has two advantages:
>>>> First, it can use many great features of virtio-net, like batching,
>>>> mergeable rx buffer and multiqueue, etc.
>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>> maintained.
>>> I'm not sure I get the motivation. Which features of
>>> virtio net are relevant to vsock? The ones that you mention
>>> all seem to be mostly of use to the networking stack.
>>>
>>>
>>>> Before the implement, I want to discuss with everyone again, and
>>>> want to know everyone's suggestions.
>>>>
>>>> After the discussion, based on this point I will try to implement
>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>> pity.:(
>>>>
>>>> -------------------------Simple idea------------------------------
>>>>
>>>> 1. The packet layout will become as follows:
>>>>
>>>> +---------------------------------+
>>>> | Virtio-net header |
>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>>>
>> Hi Michael,
>>
>> Yes, currently vsock has poor performance, first, it only support transport
>> small packet, in order to make the balance between performance and guest memory.
>>
>> In order to solve this problem, there are two features vsock can used,
>> mergeable rx buffer and multiqueue. Based on this, there are some shared
>> codes vsock can use.
>>
>> Thanks,
>> Yiwen.
> Supporting more queues with vsock is probably significantly
> less work than a completely new interface.
> For mergeable, as buffers are split arbitrarily, why can't you combine
> them within guest driver before sending them up the stack?
I don't get this question. But I think the fact that we use mergeable
buffer by default for virtio-net answer the question. Or anything
special in vsock?
Thanks
> Probably better than relying on host to do it.
>
^ permalink raw reply
* Re: [PATCH resend] can: rcar_can: convert to SPDX identifiers
From: Geert Uytterhoeven @ 2018-11-15 8:37 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Kuninori Morimoto, Wolfgang Grandegger, Linux-Renesas, netdev,
linux-can
In-Reply-To: <1bfdc10a-41e9-2a1f-b944-a8816186e998@pengutronix.de>
Hi Marc,
On Thu, Sep 27, 2018 at 11:05 AM Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 09/26/2018 03:41 AM, Kuninori Morimoto wrote:
> > From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >
> > This patch updates license to use SPDX-License-Identifier
> > instead of verbose license text.
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>
> Wolfram Sang has already supplied a similar patch, but not for Makefile
> and Kconfig. I've applied your patch for Makefile and Kconfig and
> adjusted the commit message accordingly.
Is it possible all of this fell through the cracks? There's no SPDX to be found
in drivers/net/can/rcar/ in next-20181115?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
From: Kenneth Lee @ 2018-11-15 8:51 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Kenneth Lee, Tim Sell, linux-doc, Alexander Shishkin, Zaibo Xu,
zhangfei.gao, linuxarm, haojian.zhuang, Christoph Lameter,
Hao Fang, Gavin Schenk, RDMA mailing list, Zhou Wang,
Jason Gunthorpe, Doug Ledford, Uwe Kleine-König,
David Kershner, Johan Hovold, Cyrille Pitchen
In-Reply-To: <20181114160017.GI3759@mtr-leonro.mtl.com>
On Wed, Nov 14, 2018 at 06:00:17PM +0200, Leon Romanovsky wrote:
> Date: Wed, 14 Nov 2018 18:00:17 +0200
> From: Leon Romanovsky <leon@kernel.org>
> To: Kenneth Lee <nek.in.cn@gmail.com>
> CC: Tim Sell <timothy.sell@unisys.com>, linux-doc@vger.kernel.org,
> Alexander Shishkin <alexander.shishkin@linux.intel.com>, Zaibo Xu
> <xuzaibo@huawei.com>, zhangfei.gao@foxmail.com, linuxarm@huawei.com,
> haojian.zhuang@linaro.org, Christoph Lameter <cl@linux.com>, Hao Fang
> <fanghao11@huawei.com>, Gavin Schenk <g.schenk@eckelmann.de>, RDMA mailing
> list <linux-rdma@vger.kernel.org>, Zhou Wang <wangzhou1@hisilicon.com>,
> Jason Gunthorpe <jgg@ziepe.ca>, Doug Ledford <dledford@redhat.com>, Uwe
> Kleine-König <u.kleine-koenig@pengutronix.de>, David Kershner
> <david.kershner@unisys.com>, Johan Hovold <johan@kernel.org>, Cyrille
> Pitchen <cyrille.pitchen@free-electrons.com>, Sagar Dharia
> <sdharia@codeaurora.org>, Jens Axboe <axboe@kernel.dk>,
> guodong.xu@linaro.org, linux-netdev <netdev@vger.kernel.org>, Randy Dunlap
> <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, Vinod Koul
> <vkoul@kernel.org>, linux-crypto@vger.kernel.org, Philippe Ombredanne
> <pombredanne@nexb.com>, Sanyog Kale <sanyog.r.kale@intel.com>, Kenneth Lee
> <liguozhu@hisilicon.com>, "David S. Miller" <davem@davemloft.net>,
> linux-accelerators@lists.ozlabs.org
> Subject: Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
> User-Agent: Mutt/1.10.1 (2018-07-13)
> Message-ID: <20181114160017.GI3759@mtr-leonro.mtl.com>
>
> On Wed, Nov 14, 2018 at 10:58:09AM +0800, Kenneth Lee wrote:
> >
> > 在 2018/11/13 上午8:23, Leon Romanovsky 写道:
> > > On Mon, Nov 12, 2018 at 03:58:02PM +0800, Kenneth Lee wrote:
> > > > From: Kenneth Lee <liguozhu@hisilicon.com>
> > > >
> > > > WarpDrive is a general accelerator framework for the user application to
> > > > access the hardware without going through the kernel in data path.
> > > >
> > > > The kernel component to provide kernel facility to driver for expose the
> > > > user interface is called uacce. It a short name for
> > > > "Unified/User-space-access-intended Accelerator Framework".
> > > >
> > > > This patch add document to explain how it works.
> > > + RDMA and netdev folks
> > >
> > > Sorry, to be late in the game, I don't see other patches, but from
> > > the description below it seems like you are reinventing RDMA verbs
> > > model. I have hard time to see the differences in the proposed
> > > framework to already implemented in drivers/infiniband/* for the kernel
> > > space and for the https://github.com/linux-rdma/rdma-core/ for the user
> > > space parts.
> >
> > Thanks Leon,
> >
> > Yes, we tried to solve similar problem in RDMA. We also learned a lot from
> > the exist code of RDMA. But we we have to make a new one because we cannot
> > register accelerators such as AI operation, encryption or compression to the
> > RDMA framework:)
>
> Assuming that you did everything right and still failed to use RDMA
> framework, you was supposed to fix it and not to reinvent new exactly
> same one. It is how we develop kernel, by reusing existing code.
Yes, but we don't force other system such as NIC or GPU into RDMA, do we?
I assume you would not agree to register a zip accelerator to infiniband? :)
Further, I don't think it is wise to break an exist system (RDMA) to fulfill a
totally new scenario. The better choice is to let them run in parallel for some
time and try to merge them accordingly.
>
> >
> > Another problem we tried to address is the way to pin the memory for dma
> > operation. The RDMA way to pin the memory cannot avoid the page lost due to
> > copy-on-write operation during the memory is used by the device. This may
> > not be important to RDMA library. But it is important to accelerator.
>
> Such support exists in drivers/infiniband/ from late 2014 and
> it is called ODP (on demand paging).
I reviewed ODP and I think it is a solution bound to infiniband. It is part of
MR semantics and required a infiniband specific hook
(ucontext->invalidate_range()). And the hook requires the device to be able to
stop using the page for a while for the copying. It is ok for infiniband
(actually, only mlx5 uses it). I don't think most accelerators can support
this mode. But WarpDrive works fully on top of IOMMU interface, it has no this
limitation.
>
> >
> > Hope this can help the understanding.
>
> Yes, it helped me a lot.
> Now, I'm more than before convinced that this whole patchset shouldn't
> exist in the first place.
Then maybe you can tell me how I can register my accelerator to the user space?
>
> To be clear, NAK.
>
> Thanks
>
> >
> > Cheers
> >
> > >
> > > Hard NAK from RDMA side.
> > >
> > > Thanks
> > >
> > > > Signed-off-by: Kenneth Lee <liguozhu@hisilicon.com>
> > > > ---
> > > > Documentation/warpdrive/warpdrive.rst | 260 +++++++
> > > > Documentation/warpdrive/wd-arch.svg | 764 ++++++++++++++++++++
> > > > Documentation/warpdrive/wd.svg | 526 ++++++++++++++
> > > > Documentation/warpdrive/wd_q_addr_space.svg | 359 +++++++++
> > > > 4 files changed, 1909 insertions(+)
> > > > create mode 100644 Documentation/warpdrive/warpdrive.rst
> > > > create mode 100644 Documentation/warpdrive/wd-arch.svg
> > > > create mode 100644 Documentation/warpdrive/wd.svg
> > > > create mode 100644 Documentation/warpdrive/wd_q_addr_space.svg
> > > >
> > > > diff --git a/Documentation/warpdrive/warpdrive.rst b/Documentation/warpdrive/warpdrive.rst
> > > > new file mode 100644
> > > > index 000000000000..ef84d3a2d462
> > > > --- /dev/null
> > > > +++ b/Documentation/warpdrive/warpdrive.rst
> > > > @@ -0,0 +1,260 @@
> > > > +Introduction of WarpDrive
> > > > +=========================
> > > > +
> > > > +*WarpDrive* is a general accelerator framework for the user application to
> > > > +access the hardware without going through the kernel in data path.
> > > > +
> > > > +It can be used as the quick channel for accelerators, network adaptors or
> > > > +other hardware for application in user space.
> > > > +
> > > > +This may make some implementation simpler. E.g. you can reuse most of the
> > > > +*netdev* driver in kernel and just share some ring buffer to the user space
> > > > +driver for *DPDK* [4] or *ODP* [5]. Or you can combine the RSA accelerator with
> > > > +the *netdev* in the user space as a https reversed proxy, etc.
> > > > +
> > > > +*WarpDrive* takes the hardware accelerator as a heterogeneous processor which
> > > > +can share particular load from the CPU:
> > > > +
> > > > +.. image:: wd.svg
> > > > + :alt: WarpDrive Concept
> > > > +
> > > > +The virtual concept, queue, is used to manage the requests sent to the
> > > > +accelerator. The application send requests to the queue by writing to some
> > > > +particular address, while the hardware takes the requests directly from the
> > > > +address and send feedback accordingly.
> > > > +
> > > > +The format of the queue may differ from hardware to hardware. But the
> > > > +application need not to make any system call for the communication.
> > > > +
> > > > +*WarpDrive* tries to create a shared virtual address space for all involved
> > > > +accelerators. Within this space, the requests sent to queue can refer to any
> > > > +virtual address, which will be valid to the application and all involved
> > > > +accelerators.
> > > > +
> > > > +The name *WarpDrive* is simply a cool and general name meaning the framework
> > > > +makes the application faster. It includes general user library, kernel
> > > > +management module and drivers for the hardware. In kernel, the management
> > > > +module is called *uacce*, meaning "Unified/User-space-access-intended
> > > > +Accelerator Framework".
> > > > +
> > > > +
> > > > +How does it work
> > > > +================
> > > > +
> > > > +*WarpDrive* uses *mmap* and *IOMMU* to play the trick.
> > > > +
> > > > +*Uacce* creates a chrdev for the device registered to it. A "queue" will be
> > > > +created when the chrdev is opened. The application access the queue by mmap
> > > > +different address region of the queue file.
> > > > +
> > > > +The following figure demonstrated the queue file address space:
> > > > +
> > > > +.. image:: wd_q_addr_space.svg
> > > > + :alt: WarpDrive Queue Address Space
> > > > +
> > > > +The first region of the space, device region, is used for the application to
> > > > +write request or read answer to or from the hardware.
> > > > +
> > > > +Normally, there can be three types of device regions mmio and memory regions.
> > > > +It is recommended to use common memory for request/answer descriptors and use
> > > > +the mmio space for device notification, such as doorbell. But of course, this
> > > > +is all up to the interface designer.
> > > > +
> > > > +There can be two types of device memory regions, kernel-only and user-shared.
> > > > +This will be explained in the "kernel APIs" section.
> > > > +
> > > > +The Static Share Virtual Memory region is necessary only when the device IOMMU
> > > > +does not support "Share Virtual Memory". This will be explained after the
> > > > +*IOMMU* idea.
> > > > +
> > > > +
> > > > +Architecture
> > > > +------------
> > > > +
> > > > +The full *WarpDrive* architecture is represented in the following class
> > > > +diagram:
> > > > +
> > > > +.. image:: wd-arch.svg
> > > > + :alt: WarpDrive Architecture
> > > > +
> > > > +
> > > > +The user API
> > > > +------------
> > > > +
> > > > +We adopt a polling style interface in the user space: ::
> > > > +
> > > > + int wd_request_queue(struct wd_queue *q);
> > > > + void wd_release_queue(struct wd_queue *q);
> > > > +
> > > > + int wd_send(struct wd_queue *q, void *req);
> > > > + int wd_recv(struct wd_queue *q, void **req);
> > > > + int wd_recv_sync(struct wd_queue *q, void **req);
> > > > + void wd_flush(struct wd_queue *q);
> > > > +
> > > > +wd_recv_sync() is a wrapper to its non-sync version. It will trapped into
> > > > +kernel and waits until the queue become available.
> > > > +
> > > > +If the queue do not support SVA/SVM. The following helper function
> > > > +can be used to create Static Virtual Share Memory: ::
> > > > +
> > > > + void *wd_preserve_share_memory(struct wd_queue *q, size_t size);
> > > > +
> > > > +The user API is not mandatory. It is simply a suggestion and hint what the
> > > > +kernel interface is supposed to support.
> > > > +
> > > > +
> > > > +The user driver
> > > > +---------------
> > > > +
> > > > +The queue file mmap space will need a user driver to wrap the communication
> > > > +protocol. *UACCE* provides some attributes in sysfs for the user driver to
> > > > +match the right accelerator accordingly.
> > > > +
> > > > +The *UACCE* device attribute is under the following directory:
> > > > +
> > > > +/sys/class/uacce/<dev-name>/params
> > > > +
> > > > +The following attributes is supported:
> > > > +
> > > > +nr_queue_remained (ro)
> > > > + number of queue remained
> > > > +
> > > > +api_version (ro)
> > > > + a string to identify the queue mmap space format and its version
> > > > +
> > > > +device_attr (ro)
> > > > + attributes of the device, see UACCE_DEV_xxx flag defined in uacce.h
> > > > +
> > > > +numa_node (ro)
> > > > + id of numa node
> > > > +
> > > > +priority (rw)
> > > > + Priority or the device, bigger is higher
> > > > +
> > > > +(This is not yet implemented in RFC version)
> > > > +
> > > > +
> > > > +The kernel API
> > > > +--------------
> > > > +
> > > > +The *uacce* kernel API is defined in uacce.h. If the hardware support SVM/SVA,
> > > > +The driver need only the following API functions: ::
> > > > +
> > > > + int uacce_register(uacce);
> > > > + void uacce_unregister(uacce);
> > > > + void uacce_wake_up(q);
> > > > +
> > > > +*uacce_wake_up* is used to notify the process who epoll() on the queue file.
> > > > +
> > > > +According to the IOMMU capability, *uacce* categories the devices as follow:
> > > > +
> > > > +UACCE_DEV_NOIOMMU
> > > > + The device has no IOMMU. The user process cannot use VA on the hardware
> > > > + This mode is not recommended.
> > > > +
> > > > +UACCE_DEV_SVA (UACCE_DEV_PASID | UACCE_DEV_FAULT_FROM_DEV)
> > > > + The device has IOMMU which can share the same page table with user
> > > > + process
> > > > +
> > > > +UACCE_DEV_SHARE_DOMAIN
> > > > + The device has IOMMU which has no multiple page table and device page
> > > > + fault support
> > > > +
> > > > +If the device works in mode other than UACCE_DEV_NOIOMMU, *uacce* will set its
> > > > +IOMMU to IOMMU_DOMAIN_UNMANAGED. So the driver must not use any kernel
> > > > +DMA API but the following ones from *uacce* instead: ::
> > > > +
> > > > + uacce_dma_map(q, va, size, prot);
> > > > + uacce_dma_unmap(q, va, size, prot);
> > > > +
> > > > +*uacce_dma_map/unmap* is valid only for UACCE_DEV_SVA device. It creates a
> > > > +particular PASID and page table for the kernel in the IOMMU (Not yet
> > > > +implemented in the RFC)
> > > > +
> > > > +For the UACCE_DEV_SHARE_DOMAIN device, uacce_dma_map/unmap is not valid.
> > > > +*Uacce* call back start_queue only when the DUS and DKO region is mmapped. The
> > > > +accelerator driver must use those dma buffer, via uacce_queue->qfrs[], on
> > > > +start_queue call back. The size of the queue file region is defined by
> > > > +uacce->ops->qf_pg_start[].
> > > > +
> > > > +We have to do it this way because most of current IOMMU cannot support the
> > > > +kernel and user virtual address at the same time. So we have to let them both
> > > > +share the same user virtual address space.
> > > > +
> > > > +If the device have to support kernel and user at the same time, both kernel
> > > > +and the user should use these DMA API. This is not convenient. A better
> > > > +solution is to change the future DMA/IOMMU design to let them separate the
> > > > +address space between the user and kernel space. But it is not going to be in
> > > > +a short time.
> > > > +
> > > > +
> > > > +Multiple processes support
> > > > +==========================
> > > > +
> > > > +In the latest mainline kernel (4.19) when this document is written, the IOMMU
> > > > +subsystem do not support multiple process page tables yet.
> > > > +
> > > > +Most IOMMU hardware implementation support multi-process with the concept
> > > > +of PASID. But they may use different name, e.g. it is call sub-stream-id in
> > > > +SMMU of ARM. With PASID or similar design, multi page table can be added to
> > > > +the IOMMU and referred by its PASID.
> > > > +
> > > > +*JPB* has a patchset to enable this[1]_. We have tested it with our hardware
> > > > +(which is known as *D06*). It works well. *WarpDrive* rely on them to support
> > > > +UACCE_DEV_SVA. If it is not enabled, *WarpDrive* can still work. But it
> > > > +support only one process, the device will be set to UACCE_DEV_SHARE_DOMAIN
> > > > +even it is set to UACCE_DEV_SVA initially.
> > > > +
> > > > +Static Share Virtual Memory is mainly used by UACCE_DEV_SHARE_DOMAIN device.
> > > > +
> > > > +
> > > > +Legacy Mode Support
> > > > +===================
> > > > +For the hardware without IOMMU, WarpDrive can still work, the only problem is
> > > > +VA cannot be used in the device. The driver should adopt another strategy for
> > > > +the shared memory. It is only for testing, and not recommended.
> > > > +
> > > > +
> > > > +The Folk Scenario
> > > > +=================
> > > > +For a process with allocated queues and shared memory, what happen if it forks
> > > > +a child?
> > > > +
> > > > +The fd of the queue will be duplicated on folk, so the child can send request
> > > > +to the same queue as its parent. But the requests which is sent from processes
> > > > +except for the one who open the queue will be blocked.
> > > > +
> > > > +It is recommended to add O_CLOEXEC to the queue file.
> > > > +
> > > > +The queue mmap space has a VM_DONTCOPY in its VMA. So the child will lost all
> > > > +those VMAs.
> > > > +
> > > > +This is why *WarpDrive* does not adopt the mode used in *VFIO* and *InfiniBand*.
> > > > +Both solutions can set any user pointer for hardware sharing. But they cannot
> > > > +support fork when the dma is in process. Or the "Copy-On-Write" procedure will
> > > > +make the parent process lost its physical pages.
> > > > +
> > > > +
> > > > +The Sample Code
> > > > +===============
> > > > +There is a sample user land implementation with a simple driver for Hisilicon
> > > > +Hi1620 ZIP Accelerator.
> > > > +
> > > > +To test, do the following in samples/warpdrive (for the case of PC host): ::
> > > > + ./autogen.sh
> > > > + ./conf.sh # or simply ./configure if you build on target system
> > > > + make
> > > > +
> > > > +Then you can get test_hisi_zip in the test subdirectory. Copy it to the target
> > > > +system and make sure the hisi_zip driver is enabled (the major and minor of
> > > > +the uacce chrdev can be gotten from the dmesg or sysfs), and run: ::
> > > > + mknod /dev/ua1 c <major> <minior>
> > > > + test/test_hisi_zip -z < data > data.zip
> > > > + test/test_hisi_zip -g < data > data.gzip
> > > > +
> > > > +
> > > > +References
> > > > +==========
> > > > +.. [1] https://patchwork.kernel.org/patch/10394851/
> > > > +
> > > > +.. vim: tw=78
[...]
> > > > --
> > > > 2.17.1
> > > >
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 9:02 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <015e1638-525f-7236-dbd9-38cced6b75db@redhat.com>
On 2018/11/15 16:19, Jason Wang wrote:
>
> On 2018/11/15 下午2:46, jiangyiwen wrote:
>> On 2018/11/15 12:19, Jason Wang wrote:
>>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>>> Hi Stefan, Michael, Jason and everyone,
>>>>
>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>> This idea has two advantages:
>>>> First, it can use many great features of virtio-net, like batching,
>>>> mergeable rx buffer and multiqueue, etc.
>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>> maintained.
>>>>
>>>> Before the implement, I want to discuss with everyone again, and
>>>> want to know everyone's suggestions.
>>>>
>>>> After the discussion, based on this point I will try to implement
>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>> pity. :(
>>>
>>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>>
>>>
>>>> -------------------------Simple idea------------------------------
>>>>
>>>> 1. The packet layout will become as follows:
>>>>
>>>> +---------------------------------+
>>>> | Virtio-net header |
>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>>> +---------------------------------+
>>>> | Vsock header |
>>>> | (struct virtio_vsock_hdr) |
>>>> +---------------------------------+
>>>> | payload |
>>>> | (until end of packet) |
>>>> +---------------------------------+
>>>>
>>>> 2. The Guest->Host basic code flow as follow:
>>>> +------------+
>>>> | Client |
>>>> +------------+
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |VSOCK Core Module |
>>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>>> | * hdr and payload */ |
>>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>>> |vsock hdr and payload, and then call |
>>>> +------------------------------------------------------------------+
>>>
>>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
>> Hi Jason,
>>
>> You mean we should not register netdev if use vsock, and in order to
>> avoid confusion, then I think whether we should keep vsock and export
>> some virtio-net's functions that can be shared. In this way, first, vsock
>> may keep existing architecture and will not affect virtio-net.
>
>
> At least it needs new feature bits which will be a functional duplication of virtio-net (e.g mrg_rxbuf).
Hi Jason,
Actually I mean only use some shared function to make vsock support these
features, in that way, guest see the device is still vsock device instead of
virtio-net device, in addition, it can have less codes and easier to be
compatible with old vsock version.
Thanks,
Yiwen.
>
>
>> In addition,
>> vsock doesn't need to use virtio_net header too, then it don't need to pack
>> skb structure.
>
>
> For mergeable rx buffer it need I think?
As said above, I will define the related structure in the virtio-vsock module.
>
>
>>
>> Thanks,
>> Yiwen.
>>
>>>
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |Virtio-net Module |
>>>> |start_xmit |
>>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>>> +------------------------------------------------------------------+
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |Vhost-net Module |
>>>> |handle_tx |
>>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>>> | * forward information, however vsock only need to notify server |
>>>> | * that data ready. */ |
>>>> +------------------------------------------------------------------+
>>>
>>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>>
>>>
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |VSOCK Core Module |
>>>> |alloc_pkt, copy skb data to pkt. |
>>>> |add pkt to rx_queue and notify server to get data. |
>>>> +------------------------------------------------------------------+
>>>>
>>>> 3. To Host->Guest
>>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>>> because I have been doing work related with storage and file system.
>>>>
>>>> The problem as follows:
>>>> we should monitor all of socket of vsock in handle_rx, when there are
>>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>>> get data, it is different with socket. To vsock, I think host will
>>>> not call ->recvmsg when it need to send message to guest. To net,
>>>> vhost-net only as forwarding layer.
>>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
>> For vsock, Host->Guest, it's code flow as follows:
>> Server call send()
>> -> sendmsg(); (vsock_stream_sendmsg)
>> -> virtio_trasnport_send_pkt_info
>> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>>
>> Vhost_worker
>> -> vhost_transport_send_pkt_work
>> -> get pkt from send_pkt_list
>> -> get vq input desc and then fill data to desc addr
>> -> update used ring and then signal guest
>>
>> In the whole process, host don't call recvmsg() because it is a net device, and
>> it also receives any messages.
>
>
> If I understand this correctly, there's no a socket object on host that represent vosck in guest? If yes, maybe we can invent one.
>
> Thanks
>
Sorry, I am not understanding you very much, vsock only a socket
channel, it does not have a network device entity, so it only
transmit the data between server and client, the data is only
saved in server and client. Instead of vhost-net, I feel it
has a network device that can saved the data, so when host
send message to guest, it can use recvmsg() from the
network device(tap). For Vsock, recvmsg() interface will
read message from tx vq.
>
>>
>> For vhost-net, I understand it is a tap device, so it can receive messages
>> from other net device.
>>
>> This is my understanding, it may have some errors.
>>
>> Thanks.
>>
>>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>>
>>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>>
>>> Thanks
>>>
>>>
>>> .
>>>
>>
>
> .
>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 9:21 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED361E.3090805@huawei.com>
On 2018/11/15 下午5:02, jiangyiwen wrote:
> On 2018/11/15 16:19, Jason Wang wrote:
>> On 2018/11/15 下午2:46, jiangyiwen wrote:
>>> On 2018/11/15 12:19, Jason Wang wrote:
>>>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>>>> Hi Stefan, Michael, Jason and everyone,
>>>>>
>>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>>> This idea has two advantages:
>>>>> First, it can use many great features of virtio-net, like batching,
>>>>> mergeable rx buffer and multiqueue, etc.
>>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>>> maintained.
>>>>>
>>>>> Before the implement, I want to discuss with everyone again, and
>>>>> want to know everyone's suggestions.
>>>>>
>>>>> After the discussion, based on this point I will try to implement
>>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>>> pity. :(
>>>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>>>
>>>>
>>>>> -------------------------Simple idea------------------------------
>>>>>
>>>>> 1. The packet layout will become as follows:
>>>>>
>>>>> +---------------------------------+
>>>>> | Virtio-net header |
>>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>>>> +---------------------------------+
>>>>> | Vsock header |
>>>>> | (struct virtio_vsock_hdr) |
>>>>> +---------------------------------+
>>>>> | payload |
>>>>> | (until end of packet) |
>>>>> +---------------------------------+
>>>>>
>>>>> 2. The Guest->Host basic code flow as follow:
>>>>> +------------+
>>>>> | Client |
>>>>> +------------+
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |VSOCK Core Module |
>>>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>>>> | * hdr and payload */ |
>>>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>>>> |vsock hdr and payload, and then call |
>>>>> +------------------------------------------------------------------+
>>>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
>>> Hi Jason,
>>>
>>> You mean we should not register netdev if use vsock, and in order to
>>> avoid confusion, then I think whether we should keep vsock and export
>>> some virtio-net's functions that can be shared. In this way, first, vsock
>>> may keep existing architecture and will not affect virtio-net.
>>
>> At least it needs new feature bits which will be a functional duplication of virtio-net (e.g mrg_rxbuf).
> Hi Jason,
>
> Actually I mean only use some shared function to make vsock support these
> features, in that way, guest see the device is still vsock device instead of
> virtio-net device, in addition, it can have less codes and easier to be
> compatible with old vsock version.
Yes, I think we're talking about same thing. Both of us want to share
codes. What you want is to export and share some common helpers between
virtio-net and vsock. What I meant is to e.g probe vsock device and
merge vsock specific codes into virtio-net driver. I agree it's not a
small project. We can start from e.g patches that try to share the
codes. This could also give us inspiration for how to unify them.
>
> Thanks,
> Yiwen.
>
>>
>>> In addition,
>>> vsock doesn't need to use virtio_net header too, then it don't need to pack
>>> skb structure.
>>
>> For mergeable rx buffer it need I think?
> As said above, I will define the related structure in the virtio-vsock module.
>
>>
>>> Thanks,
>>> Yiwen.
>>>
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |Virtio-net Module |
>>>>> |start_xmit |
>>>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>>>> +------------------------------------------------------------------+
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |Vhost-net Module |
>>>>> |handle_tx |
>>>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>>>> | * forward information, however vsock only need to notify server |
>>>>> | * that data ready. */ |
>>>>> +------------------------------------------------------------------+
>>>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>>>
>>>>
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |VSOCK Core Module |
>>>>> |alloc_pkt, copy skb data to pkt. |
>>>>> |add pkt to rx_queue and notify server to get data. |
>>>>> +------------------------------------------------------------------+
>>>>>
>>>>> 3. To Host->Guest
>>>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>>>> because I have been doing work related with storage and file system.
>>>>>
>>>>> The problem as follows:
>>>>> we should monitor all of socket of vsock in handle_rx, when there are
>>>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>>>> get data, it is different with socket. To vsock, I think host will
>>>>> not call ->recvmsg when it need to send message to guest. To net,
>>>>> vhost-net only as forwarding layer.
>>>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
>>> For vsock, Host->Guest, it's code flow as follows:
>>> Server call send()
>>> -> sendmsg(); (vsock_stream_sendmsg)
>>> -> virtio_trasnport_send_pkt_info
>>> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>>>
>>> Vhost_worker
>>> -> vhost_transport_send_pkt_work
>>> -> get pkt from send_pkt_list
>>> -> get vq input desc and then fill data to desc addr
>>> -> update used ring and then signal guest
>>>
>>> In the whole process, host don't call recvmsg() because it is a net device, and
>>> it also receives any messages.
>>
>> If I understand this correctly, there's no a socket object on host that represent vosck in guest? If yes, maybe we can invent one.
>>
>> Thanks
>>
> Sorry, I am not understanding you very much, vsock only a socket
> channel, it does not have a network device entity, so it only
> transmit the data between server and client, the data is only
> saved in server and client. Instead of vhost-net, I feel it
> has a network device that can saved the data, so when host
> send message to guest, it can use recvmsg() from the
> network device(tap). For Vsock, recvmsg() interface will
> read message from tx vq.
So I understand the model is not a real socket pair on host which
AF_UNIX did. Maybe it's better to have one. What I meant is, have a
socket that represent for each guest vsock device on host (guest
socket). Then when you transfer packets from host to guest, you can
queue the packets into the receive queue of the guest socket and wake up
vhost-net and it will call recvmsg() for the guest socket. And when you
want to transfer packets form guest to host, vhost_net will call
sendmsg() to the guest socket on host then it can search the correct
destination and queue packet on the receive of host socket. This can
make vsock much more easier to be integrated with vhost_net.
Thanks
>
>>> For vhost-net, I understand it is a tap device, so it can receive messages
>>> from other net device.
>>>
>>> This is my understanding, it may have some errors.
>>>
>>> Thanks.
>>>
>>>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>>>
>>>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> .
>>>>
>> .
>>
>
^ permalink raw reply
* [PATCH net] cxgb4: fix thermal zone build error
From: Ganesh Goudar @ 2018-11-15 9:23 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, dt, rdunlap, Ganesh Goudar
with CONFIG_THERMAL=m and cxgb4 as built-in build fails, and
'commit e70a57fa59bb ("cxgb4: fix thermal configuration dependencies")'
tires to fix it but when cxgb4i is made built-in build fails again,
use IS_REACHABLE instead of IS_ENABLED to fix the issue.
Fixes: e70a57fa59bb (cxgb4: fix thermal configuration dependencies)
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/Kconfig | 1 -
drivers/net/ethernet/chelsio/cxgb4/Makefile | 4 +---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++++++------
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/Kconfig b/drivers/net/ethernet/chelsio/Kconfig
index 75c1c5e..e2cdfa7 100644
--- a/drivers/net/ethernet/chelsio/Kconfig
+++ b/drivers/net/ethernet/chelsio/Kconfig
@@ -67,7 +67,6 @@ config CHELSIO_T3
config CHELSIO_T4
tristate "Chelsio Communications T4/T5/T6 Ethernet support"
depends on PCI && (IPV6 || IPV6=n)
- depends on THERMAL || !THERMAL
select FW_LOADER
select MDIO
select ZLIB_DEFLATE
diff --git a/drivers/net/ethernet/chelsio/cxgb4/Makefile b/drivers/net/ethernet/chelsio/cxgb4/Makefile
index 78e5d17..91d8a88 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/Makefile
+++ b/drivers/net/ethernet/chelsio/cxgb4/Makefile
@@ -12,6 +12,4 @@ cxgb4-objs := cxgb4_main.o l2t.o smt.o t4_hw.o sge.o clip_tbl.o cxgb4_ethtool.o
cxgb4-$(CONFIG_CHELSIO_T4_DCB) += cxgb4_dcb.o
cxgb4-$(CONFIG_CHELSIO_T4_FCOE) += cxgb4_fcoe.o
cxgb4-$(CONFIG_DEBUG_FS) += cxgb4_debugfs.o
-ifdef CONFIG_THERMAL
-cxgb4-objs += cxgb4_thermal.o
-endif
+cxgb4-$(CONFIG_THERMAL) += cxgb4_thermal.o
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 05a4692..bd85210 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5863,10 +5863,10 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!is_t4(adapter->params.chip))
cxgb4_ptp_init(adapter);
- if (IS_ENABLED(CONFIG_THERMAL) &&
- !is_t4(adapter->params.chip) && (adapter->flags & FW_OK))
+#if IS_REACHABLE(CONFIG_THERMAL)
+ if (!is_t4(adapter->params.chip) && (adapter->flags & FW_OK))
cxgb4_thermal_init(adapter);
-
+#endif
print_adapter_info(adapter);
return 0;
@@ -5932,9 +5932,9 @@ static void remove_one(struct pci_dev *pdev)
if (!is_t4(adapter->params.chip))
cxgb4_ptp_stop(adapter);
- if (IS_ENABLED(CONFIG_THERMAL))
- cxgb4_thermal_remove(adapter);
-
+#if IS_REACHABLE(CONFIG_THERMAL)
+ cxgb4_thermal_remove(adapter);
+#endif
/* If we allocated filters, free up state associated with any
* valid filters ...
*/
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] geneve: Add missing braces in addr6 initializer
From: David Miller @ 2018-11-15 19:35 UTC (permalink / raw)
To: natechancellor; +Cc: sbrivio, sd, netdev, linux-kernel
In-Reply-To: <20181112221248.11477-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Mon, 12 Nov 2018 15:12:48 -0700
> Clang warns:
>
> drivers/net/geneve.c:428:29: error: suggest braces around initialization
> of subobject [-Werror,-Wmissing-braces]
> struct in6_addr addr6 = { 0 };
> ^
> {}
>
> Fixes: a07966447f39 ("geneve: ICMP error lookup handler")
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
And this makes GCC warn.
drivers/net/geneve.c: In function ‘geneve_udp_encap_err_lookup’:
drivers/net/geneve.c:428:27: warning: missing braces around initializer [-Wmissing-braces]
struct in6_addr addr6 = { { 0 } };
^
{ }
（╯°□°）╯︵ ┻━┻
^ permalink raw reply
* Re: [PATCH net] rxrpc: Fix life check
From: David Miller @ 2018-11-15 19:36 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <154206200235.19188.1775391172980714293.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Mon, 12 Nov 2018 22:33:22 +0000
> The life-checking function, which is used by kAFS to make sure that a call
> is still live in the event of a pending signal, only samples the received
> packet serial number counter; it doesn't actually provoke a change in the
> counter, rather relying on the server to happen to give us a packet in the
> time window.
>
> Fix this by adding a function to force a ping to be transmitted.
>
> kAFS then keeps track of whether there's been a stall, and if so, uses the
> new function to ping the server, resetting the timeout to allow the reply
> to come back.
>
> If there's a stall, a ping and the call is *still* stalled in the same
> place after another period, then the call will be aborted.
>
> Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
> Fixes: f4d15fb6f99a ("rxrpc: Provide functions for allowing cleaner handling of signals")
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] cxgb4: fix thermal zone build error
From: Sergei Shtylyov @ 2018-11-15 9:30 UTC (permalink / raw)
To: Ganesh Goudar, netdev, davem; +Cc: nirranjan, indranil, dt, rdunlap
In-Reply-To: <1542273833-8546-1-git-send-email-ganeshgr@chelsio.com>
Hello!
On 15.11.2018 12:23, Ganesh Goudar wrote:
> with CONFIG_THERMAL=m and cxgb4 as built-in build fails, and
> 'commit e70a57fa59bb ("cxgb4: fix thermal configuration dependencies")'
> tires to fix it but when cxgb4i is made built-in build fails again,
Tries? :-)
> use IS_REACHABLE instead of IS_ENABLED to fix the issue.
>
> Fixes: e70a57fa59bb (cxgb4: fix thermal configuration dependencies)
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> drivers/net/ethernet/chelsio/Kconfig | 1 -
> drivers/net/ethernet/chelsio/cxgb4/Makefile | 4 +---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++++++------
> 3 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/Kconfig b/drivers/net/ethernet/chelsio/Kconfig
> index 75c1c5e..e2cdfa7 100644
> --- a/drivers/net/ethernet/chelsio/Kconfig
> +++ b/drivers/net/ethernet/chelsio/Kconfig
> @@ -67,7 +67,6 @@ config CHELSIO_T3
> config CHELSIO_T4
> tristate "Chelsio Communications T4/T5/T6 Ethernet support"
> depends on PCI && (IPV6 || IPV6=n)
> - depends on THERMAL || !THERMAL
> select FW_LOADER
> select MDIO
> select ZLIB_DEFLATE
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/Makefile b/drivers/net/ethernet/chelsio/cxgb4/Makefile
> index 78e5d17..91d8a88 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/Makefile
> +++ b/drivers/net/ethernet/chelsio/cxgb4/Makefile
> @@ -12,6 +12,4 @@ cxgb4-objs := cxgb4_main.o l2t.o smt.o t4_hw.o sge.o clip_tbl.o cxgb4_ethtool.o
> cxgb4-$(CONFIG_CHELSIO_T4_DCB) += cxgb4_dcb.o
> cxgb4-$(CONFIG_CHELSIO_T4_FCOE) += cxgb4_fcoe.o
> cxgb4-$(CONFIG_DEBUG_FS) += cxgb4_debugfs.o
> -ifdef CONFIG_THERMAL
> -cxgb4-objs += cxgb4_thermal.o
> -endif
> +cxgb4-$(CONFIG_THERMAL) += cxgb4_thermal.o
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index 05a4692..bd85210 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -5863,10 +5863,10 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (!is_t4(adapter->params.chip))
> cxgb4_ptp_init(adapter);
>
> - if (IS_ENABLED(CONFIG_THERMAL) &&
> - !is_t4(adapter->params.chip) && (adapter->flags & FW_OK))
> +#if IS_REACHABLE(CONFIG_THERMAL)
Why use #ifdef amidst a function (if you can avoid it)?
> + if (!is_t4(adapter->params.chip) && (adapter->flags & FW_OK))
> cxgb4_thermal_init(adapter);
> -
> +#endif
> print_adapter_info(adapter);
> return 0;
>
> @@ -5932,9 +5932,9 @@ static void remove_one(struct pci_dev *pdev)
>
> if (!is_t4(adapter->params.chip))
> cxgb4_ptp_stop(adapter);
> - if (IS_ENABLED(CONFIG_THERMAL))
> - cxgb4_thermal_remove(adapter);
> -
> +#if IS_REACHABLE(CONFIG_THERMAL)
> + cxgb4_thermal_remove(adapter);
> +#endif
Same question.
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH V2 net-next 2/5] net: hns3: Add handling of GRO Pkts not fully RX'ed in NAPI poll
From: Salil Mehta @ 2018-11-15 9:29 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linux-rdma, linuxarm
In-Reply-To: <20181115092925.11812-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
The "FE bit" in the description means the last description for
a packets. When HW GRO enable, HW write data to ring every
packet/buffer, there is greater probability that driver handle
with the describtion but HW still not set the "FE bit".
When drier handle the packet and HW still not set "FE bit",
driver stores skb and bd_num in rx ring, and continue to use the
skb and bd_num in next napi.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3_enet.c | 196 ++++++++++++------
.../net/ethernet/hisilicon/hns3/hns3_enet.h | 6 +
2 files changed, 140 insertions(+), 62 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index a510ddfd45a5..d8c5e1198670 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2383,6 +2383,90 @@ static bool hns3_parse_vlan_tag(struct hns3_enet_ring *ring,
}
}
+static int hns3_alloc_skb(struct hns3_enet_ring *ring, int length,
+ unsigned char *va)
+{
+#define HNS3_NEED_ADD_FRAG 1
+ struct hns3_desc_cb *desc_cb = &ring->desc_cb[ring->next_to_clean];
+ struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
+ struct sk_buff *skb;
+
+ ring->skb = napi_alloc_skb(&ring->tqp_vector->napi, HNS3_RX_HEAD_SIZE);
+ skb = ring->skb;
+ if (unlikely(!skb)) {
+ netdev_err(netdev, "alloc rx skb fail\n");
+
+ u64_stats_update_begin(&ring->syncp);
+ ring->stats.sw_err_cnt++;
+ u64_stats_update_end(&ring->syncp);
+
+ return -ENOMEM;
+ }
+
+ prefetchw(skb->data);
+
+ ring->pending_buf = 1;
+ if (length <= HNS3_RX_HEAD_SIZE) {
+ memcpy(__skb_put(skb, length), va, ALIGN(length, sizeof(long)));
+
+ /* We can reuse buffer as-is, just make sure it is local */
+ if (likely(page_to_nid(desc_cb->priv) == numa_node_id()))
+ desc_cb->reuse_flag = 1;
+ else /* This page cannot be reused so discard it */
+ put_page(desc_cb->priv);
+
+ ring_ptr_move_fw(ring, next_to_clean);
+ return 0;
+ }
+ u64_stats_update_begin(&ring->syncp);
+ ring->stats.seg_pkt_cnt++;
+ u64_stats_update_end(&ring->syncp);
+
+ ring->pull_len = eth_get_headlen(va, HNS3_RX_HEAD_SIZE);
+ __skb_put(skb, ring->pull_len);
+ hns3_nic_reuse_page(skb, 0, ring, ring->pull_len,
+ desc_cb);
+ ring_ptr_move_fw(ring, next_to_clean);
+
+ return HNS3_NEED_ADD_FRAG;
+}
+
+static int hns3_add_frag(struct hns3_enet_ring *ring, struct hns3_desc *desc,
+ struct sk_buff **out_skb, bool pending)
+{
+ struct sk_buff *skb = *out_skb;
+ struct hns3_desc_cb *desc_cb;
+ struct hns3_desc *pre_desc;
+ u32 bd_base_info;
+ int pre_bd;
+
+ /* if there is pending bd, the SW param next_to_clean has moved
+ * to next and the next is NULL
+ */
+ if (pending) {
+ pre_bd = (ring->next_to_clean - 1 + ring->desc_num) %
+ ring->desc_num;
+ pre_desc = &ring->desc[pre_bd];
+ bd_base_info = le32_to_cpu(pre_desc->rx.bd_base_info);
+ } else {
+ bd_base_info = le32_to_cpu(desc->rx.bd_base_info);
+ }
+
+ while (!hnae3_get_bit(bd_base_info, HNS3_RXD_FE_B)) {
+ desc = &ring->desc[ring->next_to_clean];
+ desc_cb = &ring->desc_cb[ring->next_to_clean];
+ bd_base_info = le32_to_cpu(desc->rx.bd_base_info);
+ if (!hnae3_get_bit(bd_base_info, HNS3_RXD_VLD_B))
+ return -ENXIO;
+
+ hns3_nic_reuse_page(skb, ring->pending_buf, ring, 0, desc_cb);
+ ring_ptr_move_fw(ring, next_to_clean);
+ ring->pending_buf++;
+ }
+
+ return 0;
+}
+
static void hns3_set_rx_skb_rss_type(struct hns3_enet_ring *ring,
struct sk_buff *skb)
{
@@ -2399,18 +2483,16 @@ static void hns3_set_rx_skb_rss_type(struct hns3_enet_ring *ring,
}
static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
- struct sk_buff **out_skb, int *out_bnum)
+ struct sk_buff **out_skb)
{
struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
+ struct sk_buff *skb = ring->skb;
struct hns3_desc_cb *desc_cb;
struct hns3_desc *desc;
- struct sk_buff *skb;
- unsigned char *va;
u32 bd_base_info;
- int pull_len;
u32 l234info;
int length;
- int bnum;
+ int ret;
desc = &ring->desc[ring->next_to_clean];
desc_cb = &ring->desc_cb[ring->next_to_clean];
@@ -2422,9 +2504,10 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
/* Check valid BD */
if (unlikely(!hnae3_get_bit(bd_base_info, HNS3_RXD_VLD_B)))
- return -EFAULT;
+ return -ENXIO;
- va = (unsigned char *)desc_cb->buf + desc_cb->page_offset;
+ if (!skb)
+ ring->va = (unsigned char *)desc_cb->buf + desc_cb->page_offset;
/* Prefetch first cache line of first page
* Idea is to cache few bytes of the header of the packet. Our L1 Cache
@@ -2433,62 +2516,42 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
* lines. In such a case, single fetch would suffice to cache in the
* relevant part of the header.
*/
- prefetch(va);
+ prefetch(ring->va);
#if L1_CACHE_BYTES < 128
- prefetch(va + L1_CACHE_BYTES);
+ prefetch(ring->va + L1_CACHE_BYTES);
#endif
- skb = *out_skb = napi_alloc_skb(&ring->tqp_vector->napi,
- HNS3_RX_HEAD_SIZE);
- if (unlikely(!skb)) {
- netdev_err(netdev, "alloc rx skb fail\n");
+ if (!skb) {
+ ret = hns3_alloc_skb(ring, length, ring->va);
+ *out_skb = skb = ring->skb;
- u64_stats_update_begin(&ring->syncp);
- ring->stats.sw_err_cnt++;
- u64_stats_update_end(&ring->syncp);
-
- return -ENOMEM;
- }
-
- prefetchw(skb->data);
-
- bnum = 1;
- if (length <= HNS3_RX_HEAD_SIZE) {
- memcpy(__skb_put(skb, length), va, ALIGN(length, sizeof(long)));
-
- /* We can reuse buffer as-is, just make sure it is local */
- if (likely(page_to_nid(desc_cb->priv) == numa_node_id()))
- desc_cb->reuse_flag = 1;
- else /* This page cannot be reused so discard it */
- put_page(desc_cb->priv);
+ if (ret < 0) /* alloc buffer fail */
+ return ret;
+ if (ret > 0) { /* need add frag */
+ ret = hns3_add_frag(ring, desc, &skb, false);
+ if (ret)
+ return ret;
- ring_ptr_move_fw(ring, next_to_clean);
+ /* As the head data may be changed when GRO enable, copy
+ * the head data in after other data rx completed
+ */
+ memcpy(skb->data, ring->va,
+ ALIGN(ring->pull_len, sizeof(long)));
+ }
} else {
- u64_stats_update_begin(&ring->syncp);
- ring->stats.seg_pkt_cnt++;
- u64_stats_update_end(&ring->syncp);
-
- pull_len = eth_get_headlen(va, HNS3_RX_HEAD_SIZE);
-
- memcpy(__skb_put(skb, pull_len), va,
- ALIGN(pull_len, sizeof(long)));
-
- hns3_nic_reuse_page(skb, 0, ring, pull_len, desc_cb);
- ring_ptr_move_fw(ring, next_to_clean);
+ ret = hns3_add_frag(ring, desc, &skb, true);
+ if (ret)
+ return ret;
- while (!hnae3_get_bit(bd_base_info, HNS3_RXD_FE_B)) {
- desc = &ring->desc[ring->next_to_clean];
- desc_cb = &ring->desc_cb[ring->next_to_clean];
- bd_base_info = le32_to_cpu(desc->rx.bd_base_info);
- hns3_nic_reuse_page(skb, bnum, ring, 0, desc_cb);
- ring_ptr_move_fw(ring, next_to_clean);
- bnum++;
- }
+ /* As the head data may be changed when GRO enable, copy
+ * the head data in after other data rx completed
+ */
+ memcpy(skb->data, ring->va,
+ ALIGN(ring->pull_len, sizeof(long)));
}
- *out_bnum = bnum;
-
l234info = le32_to_cpu(desc->rx.l234_info);
+ bd_base_info = le32_to_cpu(desc->rx.bd_base_info);
/* Based on hw strategy, the tag offloaded will be stored at
* ot_vlan_tag in two layer tag case, and stored at vlan_tag
@@ -2539,6 +2602,7 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
ring->tqp_vector->rx_group.total_bytes += skb->len;
hns3_rx_checksum(ring, skb, desc);
+ *out_skb = skb;
hns3_set_rx_skb_rss_type(ring, skb);
return 0;
@@ -2551,9 +2615,9 @@ int hns3_clean_rx_ring(
#define RCB_NOF_ALLOC_RX_BUFF_ONCE 16
struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
int recv_pkts, recv_bds, clean_count, err;
- int unused_count = hns3_desc_unused(ring);
- struct sk_buff *skb = NULL;
- int num, bnum = 0;
+ int unused_count = hns3_desc_unused(ring) - ring->pending_buf;
+ struct sk_buff *skb = ring->skb;
+ int num;
num = readl_relaxed(ring->tqp->io_base + HNS3_RING_RX_RING_FBDNUM_REG);
rmb(); /* Make sure num taken effect before the other data is touched */
@@ -2567,24 +2631,32 @@ int hns3_clean_rx_ring(
hns3_nic_alloc_rx_buffers(ring,
clean_count + unused_count);
clean_count = 0;
- unused_count = hns3_desc_unused(ring);
+ unused_count = hns3_desc_unused(ring) -
+ ring->pending_buf;
}
/* Poll one pkt */
- err = hns3_handle_rx_bd(ring, &skb, &bnum);
+ err = hns3_handle_rx_bd(ring, &skb);
if (unlikely(!skb)) /* This fault cannot be repaired */
goto out;
- recv_bds += bnum;
- clean_count += bnum;
- if (unlikely(err)) { /* Do jump the err */
- recv_pkts++;
+ if (err == -ENXIO) { /* Do not get FE for the packet */
+ goto out;
+ } else if (unlikely(err)) { /* Do jump the err */
+ recv_bds += ring->pending_buf;
+ clean_count += ring->pending_buf;
+ ring->skb = NULL;
+ ring->pending_buf = 0;
continue;
}
/* Do update ip stack process */
skb->protocol = eth_type_trans(skb, netdev);
rx_fn(ring, skb);
+ recv_bds += ring->pending_buf;
+ clean_count += ring->pending_buf;
+ ring->skb = NULL;
+ ring->pending_buf = 0;
recv_pkts++;
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 10ff18af3cc7..d8c0998127be 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -401,11 +401,17 @@ struct hns3_enet_ring {
*/
int next_to_clean;
+ int pull_len; /* head length for current packet */
+ unsigned char *va; /* first buffer address for current packet */
+
u32 flag; /* ring attribute */
int irq_init_flag;
int numa_node;
cpumask_t affinity_mask;
+
+ int pending_buf;
+ struct sk_buff *skb;
};
struct hns_queue;
--
2.17.1
^ permalink raw reply related
* [PATCH V2 net-next 3/5] net: hns3: Add support for ethtool -K to enable/disable HW GRO
From: Salil Mehta @ 2018-11-15 9:29 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linux-rdma, linuxarm
In-Reply-To: <20181115092925.11812-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
This patch adds support of ethtool -K to enable/disable
hardware GRO in HNS3 PF/VF driver.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 3 +++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 13 ++++++++++++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 9 +++++++++
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 8 ++++++++
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 21d934b7a2a3..1746172ffbf7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -305,6 +305,8 @@ struct hnae3_ae_dev {
* Set vlan filter config of vf
* enable_hw_strip_rxvtag()
* Enable/disable hardware strip vlan tag of packets received
+ * set_gro_en
+ * Enable/disable HW GRO
*/
struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -449,6 +451,7 @@ struct hnae3_ae_ops {
bool (*get_hw_reset_stat)(struct hnae3_handle *handle);
bool (*ae_dev_resetting)(struct hnae3_handle *handle);
unsigned long (*ae_dev_reset_cnt)(struct hnae3_handle *handle);
+ int (*set_gro_en)(struct hnae3_handle *handle, int enable);
};
struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index d8c5e1198670..860067898471 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1345,6 +1345,15 @@ static int hns3_nic_set_features(struct net_device *netdev,
priv->ops.maybe_stop_tx = hns3_nic_maybe_stop_tx;
}
+ if (changed & (NETIF_F_GRO_HW) && h->ae_algo->ops->set_gro_en) {
+ if (features & NETIF_F_GRO_HW)
+ ret = h->ae_algo->ops->set_gro_en(h, true);
+ else
+ ret = h->ae_algo->ops->set_gro_en(h, false);
+ if (ret)
+ return ret;
+ }
+
if ((changed & NETIF_F_HW_VLAN_CTAG_FILTER) &&
h->ae_algo->ops->enable_vlan_filter) {
if (features & NETIF_F_HW_VLAN_CTAG_FILTER)
@@ -1929,7 +1938,9 @@ static void hns3_set_default_feature(struct net_device *netdev)
NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_SCTP_CRC;
if (pdev->revision >= 0x21) {
- netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER;
+ netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER |
+ NETIF_F_GRO_HW;
+ netdev->features |= NETIF_F_GRO_HW;
if (!(h->flags & HNAE3_SUPPORT_VF)) {
netdev->hw_features |= NETIF_F_NTUPLE;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3f8bd11d0824..eb6b6a5f744f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -7667,6 +7667,14 @@ static void hclge_get_link_mode(struct hnae3_handle *handle,
}
}
+static int hclge_gro_en(struct hnae3_handle *handle, int enable)
+{
+ struct hclge_vport *vport = hclge_get_vport(handle);
+ struct hclge_dev *hdev = vport->back;
+
+ return hclge_config_gro(hdev, enable);
+}
+
static const struct hnae3_ae_ops hclge_ops = {
.init_ae_dev = hclge_init_ae_dev,
.uninit_ae_dev = hclge_uninit_ae_dev,
@@ -7738,6 +7746,7 @@ static const struct hnae3_ae_ops hclge_ops = {
.get_hw_reset_stat = hclge_get_hw_reset_stat,
.ae_dev_resetting = hclge_ae_dev_resetting,
.ae_dev_reset_cnt = hclge_ae_dev_reset_cnt,
+ .set_gro_en = hclge_gro_en,
};
static struct hnae3_ae_algo ae_algo = {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 2e889b829976..e27d6fa85a74 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2368,6 +2368,13 @@ void hclgevf_update_speed_duplex(struct hclgevf_dev *hdev, u32 speed,
hdev->hw.mac.duplex = duplex;
}
+static int hclgevf_gro_en(struct hnae3_handle *handle, int enable)
+{
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+
+ return hclgevf_config_gro(hdev, enable);
+}
+
static void hclgevf_get_media_type(struct hnae3_handle *handle,
u8 *media_type)
{
@@ -2442,6 +2449,7 @@ static const struct hnae3_ae_ops hclgevf_ops = {
.get_hw_reset_stat = hclgevf_get_hw_reset_stat,
.ae_dev_resetting = hclgevf_ae_dev_resetting,
.ae_dev_reset_cnt = hclgevf_ae_dev_reset_cnt,
+ .set_gro_en = hclgevf_gro_en,
};
static struct hnae3_ae_algo ae_algovf = {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] geneve: Add missing braces in addr6 initializer
From: Nathan Chancellor @ 2018-11-15 19:38 UTC (permalink / raw)
To: David Miller; +Cc: sbrivio, sd, netdev, linux-kernel
In-Reply-To: <20181115.113501.2215768757973757171.davem@davemloft.net>
On Thu, Nov 15, 2018 at 11:35:01AM -0800, David Miller wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
> Date: Mon, 12 Nov 2018 15:12:48 -0700
>
> > Clang warns:
> >
> > drivers/net/geneve.c:428:29: error: suggest braces around initialization
> > of subobject [-Werror,-Wmissing-braces]
> > struct in6_addr addr6 = { 0 };
> > ^
> > {}
> >
> > Fixes: a07966447f39 ("geneve: ICMP error lookup handler")
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> And this makes GCC warn.
>
> drivers/net/geneve.c: In function ‘geneve_udp_encap_err_lookup’:
> drivers/net/geneve.c:428:27: warning: missing braces around initializer [-Wmissing-braces]
> struct in6_addr addr6 = { { 0 } };
> ^
> { }
>
> （╯°□°）╯︵ ┻━┻
Yes, sorry, I thought I test built before sending it but apparently not
:( v2 should be sitting in your inbox as a reply to this one unless I
screwed that up too...
Nathan
^ permalink raw reply
* RE: [PATCH net-next 1/5] net: hns3: Enable HW GRO for Rev B(=0x21) HNS3 hardware
From: Salil Mehta @ 2018-11-15 9:36 UTC (permalink / raw)
To: Leon Romanovsky
Cc: davem@davemloft.net, Zhuangyuzeng (Yisen), lipeng (Y),
mehta.salil@opnsrc.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
Linuxarm
In-Reply-To: <20181113112446.GC3759@mtr-leonro.mtl.com>
> From: Leon Romanovsky [mailto:leon@kernel.org]
> Sent: Tuesday, November 13, 2018 11:25 AM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: davem@davemloft.net; Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>;
> lipeng (Y) <lipeng321@huawei.com>; mehta.salil@opnsrc.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> rdma@vger.kernel.org; Linuxarm <linuxarm@huawei.com>
> Subject: Re: [PATCH net-next 1/5] net: hns3: Enable HW GRO for Rev
> B(=0x21) HNS3 hardware
>
> On Tue, Nov 13, 2018 at 10:13:03AM +0000, Salil Mehta wrote:
> > From: Peng Li <lipeng321@huawei.com>
> >
> > HNS3 hardware Revision B(=0x21) supports Hardware GRO feature. This
> > patch enables this feature in the HNS3 PF/VF driver.
> >
> > Signed-off-by: Peng Li <lipeng321@huawei.com>
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> >
> > + ret = hclge_config_gro(hdev, true);
> > + if (ret) {
> > + dev_err(&pdev->dev,
> > + "Failed to enable GRO in hardware, ret =%d\n", ret);
>
> You already printed an error in the hclge_config_gro().
sure. thanks.
>
> > + goto err_mdiobus_unreg;
> > + }
> > +
> > ret = hclge_init_vlan_config(hdev);
> > if (ret) {
> > dev_err(&pdev->dev, "VLAN init fail, ret =%d\n", ret);
> > @@ -7221,6 +7250,13 @@ static int hclge_reset_ae_dev(struct hnae3_ae_dev *ae_dev)
> > return ret;
> > }
> >
> > + ret = hclge_config_gro(hdev, true);
> > + if (ret) {
> > + dev_err(&pdev->dev,
> > + "Failed to enable GRO in hardware, ret =%d\n", ret);
>
> Ditto
ok.
> > static int hclgevf_rss_init_hw(struct hclgevf_dev *hdev)
> > {
> > struct hclgevf_rss_cfg *rss_cfg = &hdev->rss_cfg;
> > @@ -2122,6 +2145,13 @@ static int hclgevf_reset_hdev(struct
> hclgevf_dev *hdev)
> > return ret;
> > }
> >
> > + ret = hclgevf_config_gro(hdev, true);
> > + if (ret) {
> > + dev_err(&pdev->dev,
> > + "failed to enable VF GRO in hardware, ret =%d\n",
> ret);
> > + return ret;
>
> Ditto
sure.
>
> > + }
> > +
> > ret = hclgevf_init_vlan_config(hdev);
> > if (ret) {
> > dev_err(&hdev->pdev->dev,
> > @@ -2199,6 +2229,13 @@ static int hclgevf_init_hdev(struct hclgevf_dev
> *hdev)
> > goto err_config;
> > }
> >
> > + ret = hclgevf_config_gro(hdev, true);
> > + if (ret) {
> > + dev_err(&pdev->dev,
> > + "Failed to enable VF GRO in hardware, ret =%d\n",
> ret);
>
> Ditto
Fixed in V2. Thanks Leon.
Best regards
Salil.
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Yan Vugenfirer @ 2018-11-15 9:36 UTC (permalink / raw)
To: jiangyiwen
Cc: stefanha, stefanha, Jason Wang, mst, netdev, kvm, virtualization
In-Reply-To: <5BECEE53.7090408@huawei.com>
> On 15 Nov 2018, at 05:56, jiangyiwen <jiangyiwen@huawei.com> wrote:
>
> Hi Stefan, Michael, Jason and everyone,
>
> Several days ago, I discussed with jason about "Vsock over Virtio-net".
> This idea has two advantages:
> First, it can use many great features of virtio-net, like batching,
> mergeable rx buffer and multiqueue, etc.
> Second, it can reduce many duplicate codes and make it easy to be
> maintained.
I would like to add that from Windows guest support perspective it makes more sense.
To support vsock we most probably need NDIS protocol driver and if it will be binded to NDIS miniport driver (the driver that currently handles virtio-net in Windows) it will make our life much easier. Otherwise we need to “plug” into NIDS on one hand, and handle transport outside of NDIS on other hand or in some strange way by creating mini port driver that is not really NIC miniport driver.
Best regards,
Yan.
>
> Before the implement, I want to discuss with everyone again, and
> want to know everyone's suggestions.
>
> After the discussion, based on this point I will try to implement
> this idea, but I am not familiar with the virtio-net, that is a
> pity. :(
>
> -------------------------Simple idea------------------------------
>
> 1. The packet layout will become as follows:
>
> +---------------------------------+
> | Virtio-net header |
> |(struct virtio_net_hdr_mrg_rxbuf)|
> +---------------------------------+
> | Vsock header |
> | (struct virtio_vsock_hdr) |
> +---------------------------------+
> | payload |
> | (until end of packet) |
> +---------------------------------+
>
> 2. The Guest->Host basic code flow as follow:
> +------------+
> | Client |
> +------------+
> |
> |
> +------------------------------------------------------------------+
> |VSOCK Core Module |
> |ops->sendmsg; (vsock_stream_sendmsg) |
> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
> | * hdr and payload */ |
> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
> |vsock hdr and payload, and then call |
> +------------------------------------------------------------------+
> |
> |
> +------------------------------------------------------------------+
> |Virtio-net Module |
> |start_xmit |
> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
> +------------------------------------------------------------------+
> |
> |
> +------------------------------------------------------------------+
> |Vhost-net Module |
> |handle_tx |
> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
> | /* This point has some differences, vhost-net use ->sendmsg to |
> | * forward information, however vsock only need to notify server |
> | * that data ready. */ |
> +------------------------------------------------------------------+
> |
> |
> +------------------------------------------------------------------+
> |VSOCK Core Module |
> |alloc_pkt, copy skb data to pkt. |
> |add pkt to rx_queue and notify server to get data. |
> +------------------------------------------------------------------+
>
> 3. To Host->Guest
> I have a problem and difficult, mainly I know about virtio-net a little),
> because I have been doing work related with storage and file system.
>
> The problem as follows:
> we should monitor all of socket of vsock in handle_rx, when there are
> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
> get data, it is different with socket. To vsock, I think host will
> not call ->recvmsg when it need to send message to guest. To net,
> vhost-net only as forwarding layer.
>
^ permalink raw reply
* Re: WARNING in bpf_check (2)
From: Edward Cree @ 2018-11-15 19:50 UTC (permalink / raw)
To: syzbot, ast, daniel, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000c9fe68057aaf48ff@google.com>
On 15/11/18 07:49, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: ccda4af0f4b9 Linux 4.20-rc2
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=129edfbd400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
> dashboard link: https://syzkaller.appspot.com/bug?extid=4fc427c7af994b0948be
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172b626d400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=148dcb0b400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4fc427c7af994b0948be@syzkaller.appspotmail.com
I'm investigating this. So far I have disassembled the prog and reproduced
the failure by adding the following to test_verifier.c:
{
"syz found: explosion",
.insns = {
BPF_MOV64_REG(BPF_REG_6, BPF_REG_1),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 1, 0, 5),
BPF_JMP_REG(BPF_JSGT, BPF_REG_0, BPF_REG_0, 0),
BPF_MOV64_REG(BPF_REG_1, BPF_REG_6),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 1, 0, 2),
BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
BPF_EXIT_INSN(),
BPF_LDX_MEM(BPF_B, BPF_REG_9, BPF_REG_1, 0),
BPF_MOV64_IMM(BPF_REG_0, 0),
BPF_EXIT_INSN(),
},
.prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
.result = ACCEPT,
},
A subprog _does_ start at insn 7, and the verifier was happy with it until
jit_subprogs, suggesting that something has mangled env->subprog_info[].start
or else insns have been inserted but the call insns not adjusted.
The obvious suspect would be adjust_subprog_starts() and/or
bpf_patch_insn_data().
-Ed
^ permalink raw reply
* Re: [PATCH v2] tg3: optionally get mac address from devicetree
From: Andrew Lunn @ 2018-11-15 20:00 UTC (permalink / raw)
To: thesven73
Cc: svendev, siva.kallam, prashant, mchan, davem, linux-kernel,
netdev, arnd
In-Reply-To: <20181114135202.27104-1-TheSven73@googlemail.com>
On Wed, Nov 14, 2018 at 08:52:01AM -0500, thesven73@gmail.com wrote:
> If the tg3 has a device node, and that node contains a valid
> mac address property, use that as the tg3's mac address.
>
> This behaviour was previously only present on SPARC, using a
> conditional compile (#ifdef CONFIG_SPARC), presumably because
> at the time, devicetree nodes for pci devices only worked on
> SPARC. However, this has recently been made universal, see
> commit 98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically")
>
> Devicetree example:
> (see Documentation/devicetree/bindings/pci/pci.txt)
>
> &pcie {
> host@0 {
> #address-cells = <3>;
> #size-cells = <2>;
> reg = <0 0 0 0 0>;
> bcm5778: bcm5778@0 {
> reg = <0 0 0 0 0>;
> mac-address = [CA 11 AB 1E 10 01];
> };
> };
> };
>
> Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 1/3] net-next/hinic:fix a bug in set mac address
From: Xue Chaojing @ 2018-11-15 20:05 UTC (permalink / raw)
To: davem
Cc: linux-kernel, xuechaojing, netdev, wulike1, chiqijun, fy.wang,
tony.qu, luoshaokai
In add_mac_addr(), if the MAC address is a muliticast address,
it will not be set, which causes the network card fail to receive
the multicast packet. This patch fixes this bug.
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
---
drivers/net/ethernet/huawei/hinic/hinic_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
index fdf2bdb6b0d0..cefd441bb117 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@ -600,9 +600,6 @@ static int add_mac_addr(struct net_device *netdev, const u8 *addr)
u16 vid = 0;
int err;
- if (!is_valid_ether_addr(addr))
- return -EADDRNOTAVAIL;
-
netif_info(nic_dev, drv, netdev, "set mac addr = %02x %02x %02x %02x %02x %02x\n",
addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
@@ -733,6 +730,9 @@ static void set_rx_mode(struct work_struct *work)
__dev_uc_sync(nic_dev->netdev, add_mac_addr, remove_mac_addr);
__dev_mc_sync(nic_dev->netdev, add_mac_addr, remove_mac_addr);
+
+ netdev_for_each_mc_addr(ha, nic_dev->netdev)
+ add_mac_addr(nic_dev->netdev, ha->addr);
}
static void hinic_set_rx_mode(struct net_device *netdev)
--
2.17.1
^ permalink raw reply related
* [PATCH 3/3] net-next/hinic: fix a bug in rx data flow
From: Xue Chaojing @ 2018-11-15 20:05 UTC (permalink / raw)
To: davem
Cc: linux-kernel, xuechaojing, netdev, wulike1, chiqijun, fy.wang,
tony.qu, luoshaokai
In-Reply-To: <20181115200548.5326-1-xuechaojing@huawei.com>
In rx_alloc_pkts(), there is a loop call of tasklet, which causes
100% cpu utilization, even no packets are being received. This patch
fixes this bug.
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
---
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.c b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
index 93e8f207f6da..f86f2e693224 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_rx.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
@@ -229,9 +229,9 @@ static int rx_alloc_pkts(struct hinic_rxq *rxq)
wmb(); /* write all the wqes before update PI */
hinic_rq_update(rxq->rq, prod_idx);
+ tasklet_schedule(&rxq->rx_task);
}
- tasklet_schedule(&rxq->rx_task);
return i;
}
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH 0/6] Armada 38x comphy driver to support 2.5Gbps networking
From: Maxime Chevallier @ 2018-11-15 10:02 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-arm-kernel, netdev, Andrew Lunn,
Gregory Clement, Jason Cooper, Kishon Vijay Abraham I,
Mark Rutland, Rob Herring, Sebastian Hesselbarth,
Thomas Petazzoni
In-Reply-To: <20181112122933.GD30658@n2100.armlinux.org.uk>
Hello Russell,
On Mon, 12 Nov 2018 12:29:33 +0000
Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>Hi,
>
>This series adds support for dynamically switching between 1Gbps
>and 2.5Gbps networking for the Marvell Armada 38x SoCs, tested on
>Armada 388 on the Clearfog platform.
I've performed some tests on my side on a Clearfog too, and also on an
Armada 385 board. It works fine on both setups.
Thanks for implementing this,
Maxime
^ permalink raw reply
* Re: [RFC PATCH 2/6] phy: armada38x: add common phy support
From: Maxime Chevallier @ 2018-11-15 10:02 UTC (permalink / raw)
To: Russell King
Cc: devicetree, linux-arm-kernel, netdev, Andrew Lunn,
Gregory Clement, Jason Cooper, Kishon Vijay Abraham I,
Mark Rutland, Rob Herring, Sebastian Hesselbarth,
Thomas Petazzoni
In-Reply-To: <E1gMBMi-00089Q-7S@rmk-PC.armlinux.org.uk>
Hi Russell,
On Mon, 12 Nov 2018 12:30:52 +0000
Russell King <rmk+kernel@armlinux.org.uk> wrote:
>Add support for the Armada 38x common phy to allow us to change the
>speed of the Ethernet serdes lane. This driver only supports
>manipulation of the speed, it does not support configuration of the
>common phy.
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH 3/6] ARM: dts: add description for Armada 38x common phy
From: Maxime Chevallier @ 2018-11-15 10:02 UTC (permalink / raw)
To: Russell King
Cc: devicetree, linux-arm-kernel, netdev, Andrew Lunn,
Gregory Clement, Jason Cooper, Kishon Vijay Abraham I,
Mark Rutland, Rob Herring, Sebastian Hesselbarth,
Thomas Petazzoni
In-Reply-To: <E1gMBMn-00089g-BV@rmk-PC.armlinux.org.uk>
Hi Russell,
On Mon, 12 Nov 2018 12:30:57 +0000
Russell King <rmk+kernel@armlinux.org.uk> wrote:
>Add the DT description for the Armada 38x common phy.
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH 6/6] ARM: dts: clearfog: add comphy settings for Ethernet interfaces
From: Maxime Chevallier @ 2018-11-15 10:02 UTC (permalink / raw)
To: Russell King
Cc: devicetree, linux-arm-kernel, netdev, Andrew Lunn,
Gregory Clement, Jason Cooper, Kishon Vijay Abraham I,
Mark Rutland, Rob Herring, Sebastian Hesselbarth,
Thomas Petazzoni
In-Reply-To: <E1gMBN2-0008AQ-Nk@rmk-PC.armlinux.org.uk>
Hi Russell,
On Mon, 12 Nov 2018 12:31:12 +0000
Russell King <rmk+kernel@armlinux.org.uk> wrote:
>Add the comphy settings for the Ethernet interfaces.
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
^ permalink raw reply
* Re: [RFC PATCH 5/6] net: marvell: neta: add support for 2500base-X
From: Maxime Chevallier @ 2018-11-15 10:02 UTC (permalink / raw)
To: Russell King
Cc: devicetree, linux-arm-kernel, netdev, Andrew Lunn,
Gregory Clement, Jason Cooper, Kishon Vijay Abraham I,
Mark Rutland, Rob Herring, Sebastian Hesselbarth,
Thomas Petazzoni
In-Reply-To: <E1gMBMx-0008A9-Jb@rmk-PC.armlinux.org.uk>
Hi Russell,
On Mon, 12 Nov 2018 12:31:07 +0000
Russell King <rmk+kernel@armlinux.org.uk> wrote:
Maybe missing a commit log ?
Otherwise,
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ 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