In the case of XDP-PASS, skb_reserve uses the delta to compatible
non-XDP, now remove this logic.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 34220f5f27d1.
This patch introduce a new function that frees the rest mergeable buf.
The subsequent patch will reuse this function.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --g
This patch introduce a new function that releases the
xdp shinfo. The subsequent patch will reuse this function.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/n
now, the process of xdp is simple, we can remove the skip_xdp.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5a5636178bd3..19f7a8367c
Avoid the problem that some variables(headroom and so on) will repeat
the calculation when process xdp.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index
Now, the logic of merge xdp process is simple, we can remove the
skip_xdp.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 42e9927e316b..a
virtnet_build_xdp_buff_mrg() and virtnet_xdp_handler() auto
release xdp shinfo then the caller no need to careful the xdp shinfo.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/net/
The purpose of this patch is to simplify the receive_small().
Separate all the logic of XDP of small into a function.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 165 +++
1 file changed, 99 insertions(+), 66 deletions(-)
diff --git a/drivers/net/v
The purpose of this patch is to simplify the receive_mergeable().
Separate all the logic of XDP into a function.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 100 ---
1 file changed, 61 insertions(+), 39 deletions(-)
diff --git a/drivers/net/virtio
At present, we have two similar logic to perform the XDP prog.
Therefore, this PATCH separates the code of executing XDP, which is
conducive to later maintenance.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 118 +++
1 file changed, 58 insertions(+
The previous patch, in order to facilitate review, I do not do any
modification. This patch has made some optimization on the top.
* remove some repeated logics in this function.
* add fast check for passing without any alloc.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 29 +
In the xdp implementation of virtio-net mergeable, it always checks
whether two page is used and a page is selected to release. This is
complicated for the processing of action, and be careful.
In the entire process, we have such principles:
* If xdp_page is used (PASS, TX, Redirect), then we rele
Due to historical reasons, the implementation of XDP in virtio-net is relatively
chaotic. For example, the processing of XDP actions has two copies of similar
code. Such as page, xdp_page processing, etc.
The purpose of this patch set is to refactor these code. Reduce the difficulty
of subsequent
virtnet_xdp_handler() is to process all the logic related to XDP. The
caller only needs to care about how to deal with the buf. So this commit
introduces new enums:
1. VIRTNET_XDP_RES_PASS: make skb by the buf
2. VIRTNET_XDP_RES_DROP: xdp return drop action or some error, caller
should release
Separating the logic of preparation for xdp from receive_mergeable.
The purpose of this is to simplify the logic of execution of XDP.
The main logic here is that when headroom is insufficient, we need to
allocate a new page and calculate offset. It should be noted that if
there is new page, the v
On Tue, 11 Apr 2023 05:16:19 -0700, Christoph Hellwig
wrote:
> On Tue, Apr 11, 2023 at 03:23:43PM +0800, Xuan Zhuo wrote:
> > > If a direct map or not is used is a decision done by the platform code,
> > > often based on firmware tables. You can't just override that.
> >
> >
> > Can Virtio Devic
On Mon, Apr 17, 2023 at 07:54:00PM -0700, Jakub Kicinski wrote:
> AF_XDP, io_uring, and increasing number of pinned memory / zero copy
> implementations need to do DMA mapping outside the drivers.
You can't just do dma mapping outside the driver, because there are
drivers that do not require DMA m
On Mon, 17 Apr 2023 18:19:50 -0700, Jakub Kicinski wrote:
> On Tue, 18 Apr 2023 09:07:30 +0800 Jason Wang wrote:
> > > > Would you mind explaining this a bit more to folks like me who are not
> > > > familiar with VirtIO? DMA API is supposed to hide the DMA mapping
> > > > details from the stack,
On Mon, 17 Apr 2023 11:57:53 -0700, Jakub Kicinski wrote:
> On Mon, 17 Apr 2023 11:56:10 -0700 Jakub Kicinski wrote:
> > > May misunderstand, here the "dma_ops" is not the "dma_ops" of DMA API.
> > >
> > > I mean the callbacks for xsk to do dma.
> > >
> > > Maybe, I should rename it in the next ve
On Tue, Apr 18, 2023 at 2:58 AM Jakub Kicinski wrote:
>
> On Mon, 17 Apr 2023 11:56:10 -0700 Jakub Kicinski wrote:
> > > May misunderstand, here the "dma_ops" is not the "dma_ops" of DMA API.
> > >
> > > I mean the callbacks for xsk to do dma.
> > >
> > > Maybe, I should rename it in the next vers
> > Signed-off-by: Alvaro Karsz
>
> Acked-by: Jason Wang
>
Thanks Jason.
BTW, Michael, I see that you merged the first version into the mst tree.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation
On Mon, Apr 17, 2023 at 11:51:22AM +, Alvaro Karsz wrote:
> > > I see your point.
> > > Regardless, we'll need to fail probe in some cases.
> > > ring size of 1 for example (if I'm not mistaken)
> >
> > Hmm. We can make it work if we increase hard header size, then
> > there will always be roo
> > I see your point.
> > Regardless, we'll need to fail probe in some cases.
> > ring size of 1 for example (if I'm not mistaken)
>
> Hmm. We can make it work if we increase hard header size, then
> there will always be room for vnet header.
>
> > control vq even needs a bigger ring.
>
> Why do
And in fact this is v6, isn't it? Similar to v6 but
rebased?
On Mon, Apr 17, 2023 at 02:03:43PM +0300, Eli Cohen wrote:
> Current code ignores link state updates if VIRTIO_NET_F_STATUS was not
> negotiated. However, link state updates could be received before feature
> negotiation was completed ,
On Mon, Apr 17, 2023 at 10:04:56AM +, Alvaro Karsz wrote:
> > > So, what do you think, we should fix virtio-net to work with smaller
> > > rings? we should fail probe?
> > >
> > > I think that since this never came up until now, there is no big demand
> > > to such small rings.
> >
> > The w
On Mon, Apr 17, 2023 at 02:03:43PM +0300, Eli Cohen wrote:
> Current code ignores link state updates if VIRTIO_NET_F_STATUS was not
> negotiated. However, link state updates could be received before feature
> negotiation was completed , therefore causing link state events to be
> lost, possibly lea
On Mon, Apr 17, 2023 at 02:03:43PM +0300, Eli Cohen wrote:
> Current code ignores link state updates if VIRTIO_NET_F_STATUS was not
> negotiated. However, link state updates could be received before feature
> negotiation was completed , therefore causing link state events to be
> lost, possibly lea
On 15.04.23 14:09, Lorenzo Stoakes wrote:
After the introduction of FOLL_SAME_FILE we no longer require vmas for any
invocation of pin_user_pages(), so eliminate this parameter from the
function and all callers.
This clears the way to removing the vmas parameter from GUP altogether.
Signed-off-
> > So, what do you think, we should fix virtio-net to work with smaller rings?
> > we should fail probe?
> >
> > I think that since this never came up until now, there is no big demand to
> > such small rings.
>
> The worry is that once we start failing probe there's just a tiny chance
> hosts
On Mon, Apr 17, 2023 at 07:33:58AM +, Alvaro Karsz wrote:
> > > > > > Actually, I think that all you need to do is disable NETIF_F_SG,
> > > > > > and things will work, no?
> > > > >
> > > > > I think that this is not so simple, if I understand correctly, by
> > > > > disabling NETIF_F_SG we w
Implement the kick_vq_with_data vDPA callback.
On kick, we pass the next available data to the DPU by writing it in
the kick offset.
Signed-off-by: Alvaro Karsz
---
Should be applied on top of:
https://lore.kernel.org/virtualization/20230413081855.36643-1-alvaro.ka...@solid-run.com/
drivers/vdp
On Thu, Apr 13, 2023 at 3:33 PM Alvaro Karsz wrote:
>
> When suspend is called, the driver sends a suspend command to the DPU
> through the control mechanism.
>
> Signed-off-by: Alvaro Karsz
Acked-by: Jason Wang
Thanks
> ---
> drivers/vdpa/solidrun/snet_ctrl.c | 6 ++
> drivers/vdpa/sol
On Thu, Apr 13, 2023 at 3:33 PM Alvaro Karsz wrote:
>
> This patch adds the get_vq_state and set_vq_state vDPA callbacks.
>
> In order to get the VQ state, the state needs to be read from the DPU.
> In order to allow that, the old messaging mechanism is replaced with a new,
> flexible control mech
On Thu, Apr 13, 2023 at 4:19 PM Alvaro Karsz wrote:
>
> Add VIRTIO_F_NOTIFICATION_DATA support for vDPA transport.
> If this feature is negotiated, the driver passes extra data when kicking
> a virtqueue.
>
> A device that offers this feature needs to implement the
> kick_vq_with_data callback.
>
> > > > > Actually, I think that all you need to do is disable NETIF_F_SG,
> > > > > and things will work, no?
> > > >
> > > > I think that this is not so simple, if I understand correctly, by
> > > > disabling NETIF_F_SG we will never receive a chained skbs to transmit,
> > > > but we still have
On Mon, Apr 17, 2023 at 07:07:59AM +, Alvaro Karsz wrote:
> > Why tx timeout without frags?
>
> Please see my response to Michael.
>
> > > * Guest GSO/big MTU (without VIRTIO_NET_F_MRG_RXBUF?), we can't chain
> > > page size buffers anymore.
> >
> >
> > Or, we disable the GUEST_GSO, HOST_G
On Mon, Apr 17, 2023 at 07:03:52AM +, Alvaro Karsz wrote:
> > > > Actually, I think that all you need to do is disable NETIF_F_SG,
> > > > and things will work, no?
> > >
> > > I think that this is not so simple, if I understand correctly, by
> > > disabling NETIF_F_SG we will never receive a
> Why tx timeout without frags?
Please see my response to Michael.
> > * Guest GSO/big MTU (without VIRTIO_NET_F_MRG_RXBUF?), we can't chain page
> > size buffers anymore.
>
>
> Or, we disable the GUEST_GSO, HOST_GSO..
>
And disable VIRTIO_NET_F_MTU, quoting the spec:
"A driver SHOULD neg
> > > Actually, I think that all you need to do is disable NETIF_F_SG,
> > > and things will work, no?
> >
> > I think that this is not so simple, if I understand correctly, by disabling
> > NETIF_F_SG we will never receive a chained skbs to transmit, but we still
> > have more functionality to a
39 matches
Mail list logo
