On Mon, Mar 20, 2023 at 09:29:50PM -0500, michael.chris...@oracle.com wrote:
> On 3/20/23 9:06 PM, Mike Christie wrote:
> > The following patches were made over Linus tree.
>
> Hi Michael, I see you merged my first version of the patchset in your
> vhost branch.
>
> Do you want me to just send a
On Tue, Mar 21, 2023 at 10:29:11AM +0800, Jason Wang wrote:
> On Tue, Mar 21, 2023 at 7:21 AM Viktor Prutyanov wrote:
> >
> > According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
> > indicates that the driver passes extra data along with the queue
> > notifications.
> >
> > In a split
On Mon, Mar 20, 2023 at 09:02:19PM +0300, Arseniy Krasnov wrote:
On 20.03.2023 17:29, Stefano Garzarella wrote:
On Sun, Mar 19, 2023 at 09:46:10PM +0300, Arseniy Krasnov wrote:
This adds small optimization for tx path: instead of allocating single
skbuff on every call to transport, allocate m
On Mon, Mar 20, 2023 at 09:10:13PM +0300, Arseniy Krasnov wrote:
On 20.03.2023 17:57, Stefano Garzarella wrote:
On Sun, Mar 19, 2023 at 09:51:06PM +0300, Arseniy Krasnov wrote:
This fixes header length calculation of skbuff during data appending to
it. When such skbuff is processed in dequeue
On Tue, Mar 21, 2023 at 12:31:48AM +0300, Arseniy Krasnov wrote:
This adds small optimization for tx path: instead of allocating single
skbuff on every call to transport, allocate multiple skbuff's until
credit space allows, thus trying to send as much as possible data without
return to af_vsock.
On Tue, Mar 21, 2023 at 12:00:42PM +0300, Viktor Prutyanov wrote:
> On Tue, Mar 21, 2023 at 5:29 AM Jason Wang wrote:
> >
> > On Tue, Mar 21, 2023 at 7:21 AM Viktor Prutyanov wrote:
> > >
> > > According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
> > > indicates that the driver passe
On Tue, Mar 21, 2023 at 02:21:15AM +0300, Viktor Prutyanov wrote:
> According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
> indicates that the driver passes extra data along with the queue
> notifications.
>
> In a split queue case, the extra data is 16-bit available index. In a
> pack
On Tue, Mar 21, 2023 at 02:21:15AM +0300, Viktor Prutyanov wrote:
> According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
> indicates that the driver passes extra data along with the queue
> notifications.
>
> In a split queue case, the extra data is 16-bit available index. In a
> pack
On Tue, Mar 21, 2023 at 11:24:34AM +0200, Eli Cohen wrote:
>
> On 20/03/2023 22:02, Michael S. Tsirkin wrote:
> > On Mon, Mar 20, 2023 at 01:49:30PM +0200, Eli Cohen wrote:
> > > One can still enable it when creating the vdpa device using vdpa tool by
> > > providing features that include it.
> >
DMA-related logic is separated from the virtqueue_add_split() to
one new function. DMA address will be saved as sg->dma_address if
use_dma_api is true, then virtqueue_add_split() will use it directly.
Unmap operation will be simpler.
The purpose of this is to facilitate subsequent support to recei
DMA-related logic is separated from the virtqueue_add_indirect_packed().
DMA address will be saved as sg->dma_address, then
virtqueue_add_indirect_packed() will use it directly. Unmap operation
will be simpler.
The purpose of this is to facilitate subsequent support to receive
dma address mapped
Update the document of virtqueue_add_* series API, allowing the callers to
use sg->dma_address to pass the dma address to Virtio Core.
Signed-off-by: Xuan Zhuo
---
drivers/virtio/virtio_ring.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c b/dr
XDP socket(AF_XDP) is an excellent bypass kernel network framework. The zero
copy feature of xsk (XDP socket) needs to be supported by the driver. The
performance of zero copy is very good.
ENV: Qemu with vhost.
vhost cpu | Guest APP CPU |Guest Softirq CPU | PPS
---
virtio core only supports virtual addresses, dma is completed in virtio
core.
In some scenarios (such as the AF_XDP), the memory is allocated
and DMA mapping is completed in advance, so it is necessary for us to
support passing the DMA address to virtio core.
Drives can use sg->dma_address to pas
Added virtqueue_dma_dev() to get DMA device for virtio. Then the
caller can do dma operation in advance. The purpose is to keep memory
mapped across multiple add/get buf operations.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio.c | 6 ++
drivers/virtio/virtio
DMA-related logic is separated from the virtqueue_add_packed(). DMA
address will be saved as sg->dma_address, then virtqueue_add_packed()
will use it directly. Unmap operation will be simpler.
The purpose of this is to facilitate subsequent support to receive
dma address mapped by drivers.
Signed
virtio core only supports virtual addresses, dma is completed in virtio
core.
In some scenarios (such as the AF_XDP), the memory is allocated
and DMA mapping is completed in advance, so it is necessary for us to
support passing the DMA address to virtio core.
Drives can use sg->dma_address to pas
virtio core only supports virtual addresses, dma is completed in virtio
core.
In some scenarios (such as the AF_XDP), the memory is allocated
and DMA mapping is completed in advance, so it is necessary for us to
support passing the DMA address to virtio core.
Drives can use sg->dma_address to pas
The subsequent reset function will reuse these logic.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 58
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ri
Modify the "useless" to a more accurate "unused".
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index d214a8a2fd4b..6f093528afd0 10064
Introduce virtqueue_reset() to release all buffer inside vq.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 33 +
include/linux/virtio.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c
On Wed, 15 Mar 2023 12:10:34 +0800, Xuan Zhuo
wrote:
> 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
On Tue, Mar 21, 2023 at 02:49:13PM +0300, Viktor Prutyanov wrote:
> On Tue, Mar 21, 2023 at 12:23 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Mar 21, 2023 at 02:21:15AM +0300, Viktor Prutyanov wrote:
> > > According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
> > > indicates that the
On Tue, 21 Mar 2023 19:58:49 +0800, Xuan Zhuo
wrote:
> On Wed, 15 Mar 2023 12:10:34 +0800, Xuan Zhuo
> wrote:
> > 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
On Tue, Mar 21, 2023 at 08:20:20PM +0800, Xuan Zhuo wrote:
> On Tue, 21 Mar 2023 19:58:49 +0800, Xuan Zhuo
> wrote:
> > On Wed, 15 Mar 2023 12:10:34 +0800, Xuan Zhuo
> > wrote:
> > > Due to historical reasons, the implementation of XDP in virtio-net is
> > > relatively
> > > chaotic. For examp
On Tue, Mar 21 2023, "Michael S. Tsirkin" wrote:
> On Tue, Mar 21, 2023 at 12:00:42PM +0300, Viktor Prutyanov wrote:
>> On Tue, Mar 21, 2023 at 5:29 AM Jason Wang wrote:
>> >
>> > On Tue, Mar 21, 2023 at 7:21 AM Viktor Prutyanov wrote:
>> > >
>> > > According to VirtIO spec v1.2, VIRTIO_F_NOTIF
On Tue, Mar 21, 2023 at 04:44:10PM +0300, Viktor Prutyanov wrote:
> According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
> indicates that the driver passes extra data along with the queue
> notifications.
>
> In a split queue case, the extra data is 16-bit available index. In a
> pack
On Tue, Mar 21 2023, Viktor Prutyanov wrote:
> According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
> indicates that the driver passes extra data along with the queue
> notifications.
>
> In a split queue case, the extra data is 16-bit available index. In a
> packed queue case, the e
On Tue, Mar 21 2023, Viktor Prutyanov wrote:
> On Tue, Mar 21, 2023 at 5:59 PM Cornelia Huck wrote:
>>
>> On Tue, Mar 21 2023, Viktor Prutyanov wrote:
>>
>> > According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
>> > indicates that the driver passes extra data along with the queue
These new optional callbacks is used to bind/unbind the device to
a specific address space so the vDPA framework can use VA when
these callbacks are implemented.
Suggested-by: Jason Wang
Signed-off-by: Stefano Garzarella
---
Notes:
v2:
- removed `struct task_struct *owner` param (unused
This series adds support for the use of user virtual addresses in the
vDPA simulator devices.
The main reason for this change is to lift the pinning of all guest memory.
Especially with virtio devices implemented in software.
The next step would be to generalize the code in vdpa-sim to allow the
When the user call VHOST_SET_OWNER ioctl and the vDPA device
has `use_va` set to true, let's call the bind_mm callback.
In this way we can bind the device to the user address space
and directly use the user VA.
The unbind_mm callback is called during the release after
stopping the device.
Signed-
kmap_atomic() is deprecated in favor of kmap_local_page() since commit
f3ba3c710ac5 ("mm/highmem: Provide kmap_local*").
With kmap_local_page() the mappings are per thread, CPU local, can take
page-faults, and can be called from any context (including interrupts).
Furthermore, the tasks can be pre
vDPA supports the possibility to use user VA in the iotlb messages.
So, let's add support for user VA in vringh to use it in the vDPA
simulators.
Signed-off-by: Stefano Garzarella
---
Notes:
v3:
- refactored avoiding code duplication [Eugenio]
v2:
- replace kmap_atomic() with kma
The spinlock we use to protect the state of the simulator is sometimes
held for a long time (for example, when devices handle requests).
This also prevents us from calling functions that might sleep (such as
kthread_flush_work() in the next patch), and thus having to release
and retake the lock.
The new "use_va" module parameter (default: true) is used in
vdpa_alloc_device() to inform the vDPA framework that the device
supports VA.
vringh is initialized to use VA only when "use_va" is true and the
user's mm has been bound. So, only when the bus supports user VA
(e.g. vhost-vdpa).
vdpasim
Let's move work management inside the vdpa_sim core.
This way we can easily change how we manage the works, without
having to change the devices each time.
Acked-by: Eugenio Pérez Martin
Acked-by: Jason Wang
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.h | 3 ++-
Let's use our own kthread to run device jobs.
This allows us more flexibility, especially we can attach the kthread
to the user address space when vDPA uses user's VA.
Acked-by: Jason Wang
Signed-off-by: Stefano Garzarella
---
Notes:
v3:
- fix `dev` not initialized in the error path [Si
On Tue, Mar 21, 2023 at 04:30:57PM +0100, Cornelia Huck wrote:
> On Tue, Mar 21 2023, Viktor Prutyanov wrote:
>
> > On Tue, Mar 21, 2023 at 5:59 PM Cornelia Huck wrote:
> >>
> >> On Tue, Mar 21 2023, Viktor Prutyanov wrote:
> >>
> >> > According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA f
On Tue, Mar 21 2023, "Michael S. Tsirkin" wrote:
> On Tue, Mar 21, 2023 at 04:30:57PM +0100, Cornelia Huck wrote:
>> On Tue, Mar 21 2023, Viktor Prutyanov wrote:
>>
>> > On Tue, Mar 21, 2023 at 5:59 PM Cornelia Huck wrote:
>> >>
>> >> On Tue, Mar 21 2023, Viktor Prutyanov wrote:
>> >>
>> >> >
On 3/21/23 2:12 AM, Michael S. Tsirkin wrote:
> On Mon, Mar 20, 2023 at 09:29:50PM -0500, michael.chris...@oracle.com wrote:
>> On 3/20/23 9:06 PM, Mike Christie wrote:
>>> The following patches were made over Linus tree.
>>
>> Hi Michael, I see you merged my first version of the patchset in your
>
On 3/21/23 12:03 PM, syzbot wrote:
> RIP: 0010:vhost_task_start+0x22/0x40 kernel/vhost_task.c:115
> Code: 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 53 48 89 fb e8 c3 67 2c 00 48 8d 7b
> 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0a 48
> 8b 7b 70 5b e9 fe bd 02 00 e8 79 ec 7e
On Tue, Mar 21, 2023 at 12:46:04PM -0500, Mike Christie wrote:
> On 3/21/23 12:03 PM, syzbot wrote:
> > RIP: 0010:vhost_task_start+0x22/0x40 kernel/vhost_task.c:115
> > Code: 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 53 48 89 fb e8 c3 67 2c 00 48 8d
> > 7b 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1
Hi,
thanks for testing the patchset.
Am 21.03.23 um 16:23 schrieb Sui jingfeng:
On 2023/3/20 23:07, Thomas Zimmermann wrote:
Remove all codepaths that implement fbdev output directly on GEM
buffers. Always allocate a shadow buffer in system memory and set
up deferred I/O for mmap.
The fbdev
On Tue, Mar 21, 2023 at 05:34:59PM +0800, Xuan Zhuo wrote:
> virtio core only supports virtual addresses, dma is completed in virtio
> core.
>
> In some scenarios (such as the AF_XDP), the memory is allocated
> and DMA mapping is completed in advance, so it is necessary for us to
> support passing
On Tue, Mar 21, 2023 at 01:55:00PM -0400, Michael S. Tsirkin wrote:
> On Tue, Mar 21, 2023 at 12:46:04PM -0500, Mike Christie wrote:
> > On 3/21/23 12:03 PM, syzbot wrote:
> > > RIP: 0010:vhost_task_start+0x22/0x40 kernel/vhost_task.c:115
> > > Code: 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 53 48 89 fb
On 3/21/2023 4:28 AM, Eli Cohen wrote:
Following patch adds driver support for VIRTIO_NET_F_MRG_RXBUF.
Current firmware versions show degradation in packet rate when using
MRG_RXBUF. Users who favor memory saving over packet rate could enable
this feature but we want to keep it off by defaul
On Tue, 21 Mar 2023 16:45:21 -0400, "Michael S. Tsirkin"
wrote:
> On Tue, Mar 21, 2023 at 05:34:59PM +0800, Xuan Zhuo wrote:
> > virtio core only supports virtual addresses, dma is completed in virtio
> > core.
> >
> > In some scenarios (such as the AF_XDP), the memory is allocated
> > and DMA ma
On Tue, Mar 21, 2023 at 4:29 PM Eli Cohen wrote:
>
> > -Original Message-
> > From: Jason Wang
> > Sent: Tuesday, 21 March 2023 5:23
> > To: Eli Cohen
> > Cc: m...@redhat.com; si-wei@oracle.com; epere...@redhat.com;
> > virtualization@lists.linux-foundation.org; Parav Pandit
> >
> >
On Wed, Feb 15, 2023 at 03:33:44PM -0700, Ross Zwisler wrote:
> Changes in v2:
> * Dropped patches which were pulled into maintainer trees.
> * Split BPF patches out into another series targeting bpf-next.
> * trace-agent now falls back to debugfs if tracefs isn't present.
> * Added Acked-by fr
On Tue, Mar 21, 2023 at 5:00 PM Albert Huang
wrote:
>
> From: "huangjie.albert"
>
> fix commit 8d622d21d248 ("virtio: fix up virtio_disable_cb")
>
> if we disable the napi_tx. when we triger a tx interrupt, the
typo should be "trigger"
> vq->event_triggered will be set to true. It will no longe
DMA-related logic is separated from the virtqueue_add_indirect_packed().
DMA address will be saved as sg->dma_address, then
virtqueue_add_indirect_packed() will use it directly. Unmap operation
will be simpler.
The purpose of this is to facilitate subsequent support to receive
dma address mapped
virtio core only supports virtual addresses, dma is completed in virtio
core.
In some scenarios (such as the AF_XDP), the memory is allocated
and DMA mapping is completed in advance, so it is necessary for us to
support passing the DMA address to virtio core.
Drives can use sg->dma_address to pas
virtio core only supports virtual addresses, dma is completed in virtio
core.
In some scenarios (such as the AF_XDP), the memory is allocated
and DMA mapping is completed in advance, so it is necessary for us to
support passing the DMA address to virtio core.
Drives can use sg->dma_address to pas
DMA-related logic is separated from the virtqueue_add_packed(). DMA
address will be saved as sg->dma_address, then virtqueue_add_packed()
will use it directly. Unmap operation will be simpler.
The purpose of this is to facilitate subsequent support to receive
dma address mapped by drivers.
Signed
XDP socket(AF_XDP) is an excellent bypass kernel network framework. The zero
copy feature of xsk (XDP socket) needs to be supported by the driver. The
performance of zero copy is very good.
ENV: Qemu with vhost.
vhost cpu | Guest APP CPU |Guest Softirq CPU | PPS
---
Update the document of virtqueue_add_* series API, allowing the callers to
use sg->dma_address to pass the dma address to Virtio Core.
Signed-off-by: Xuan Zhuo
---
drivers/virtio/virtio_ring.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c b/dr
Introduce virtqueue_reset() to release all buffer inside vq.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 33 +
include/linux/virtio.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c
Modify the "useless" to a more accurate "unused".
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 6b2334951e5f..a31cf71c1689 10064
virtio core only supports virtual addresses, dma is completed in virtio
core.
In some scenarios (such as the AF_XDP), the memory is allocated
and DMA mapping is completed in advance, so it is necessary for us to
support passing the DMA address to virtio core.
Drives can use sg->dma_address to pas
DMA-related logic is separated from the virtqueue_add_split() to
one new function. DMA address will be saved as sg->dma_address if
use_dma_api is true, then virtqueue_add_split() will use it directly.
Unmap operation will be simpler.
The purpose of this is to facilitate subsequent support to recei
Added virtqueue_dma_dev() to get DMA device for virtio. Then the
caller can do dma operation in advance. The purpose is to keep memory
mapped across multiple add/get buf operations.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio.c | 6 ++
drivers/virtio/virtio
The subsequent reset function will reuse these logic.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 58
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ri
This patch introduce a new function that frees the rest mergeable buf.
The subsequent patch will reuse this function.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/net/virti
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 | 142 +--
1 file changed, 75 insertions(+
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
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
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 | 128 +++
1 file changed, 76 insertions(+), 52 deletions(-)
diff --git a/drivers/net/virtio
This patch introduce a new function that releases the
xdp shinfo. The subsequent patch will reuse this function.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/net/virtio_net.c b/driv
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
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, 97 insertions(+), 68 deletions(-)
diff --git a/drivers/net/v
On Tue, Mar 21, 2023 at 01:28:08PM +0200, Eli Cohen wrote:
> Following patch adds driver support for VIRTIO_NET_F_MRG_RXBUF.
>
> Current firmware versions show degradation in packet rate when using
> MRG_RXBUF. Users who favor memory saving over packet rate could enable
> this feature but we want
On Wed, Mar 22, 2023 at 11:03:00AM +0800, Xuan Zhuo wrote:
> 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 p
On Tue, Mar 21, 2023 at 11:32:36PM -0400, Michael S. Tsirkin wrote:
> On Tue, Mar 21, 2023 at 01:28:08PM +0200, Eli Cohen wrote:
> > Following patch adds driver support for VIRTIO_NET_F_MRG_RXBUF.
> >
> > Current firmware versions show degradation in packet rate when using
> > MRG_RXBUF. Users who
On Tue, 21 Mar 2023 23:34:43 -0400, "Michael S. Tsirkin"
wrote:
> On Wed, Mar 22, 2023 at 11:03:00AM +0800, Xuan Zhuo wrote:
> > 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
> > sim
On Wed, Mar 22, 2023 at 11:40:56AM +0800, Xuan Zhuo wrote:
> On Tue, 21 Mar 2023 23:34:43 -0400, "Michael S. Tsirkin"
> wrote:
> > On Wed, Mar 22, 2023 at 11:03:00AM +0800, Xuan Zhuo wrote:
> > > Due to historical reasons, the implementation of XDP in virtio-net is
> > > relatively
> > > chaotic
On Tue, 21 Mar 2023 23:53:52 -0400, "Michael S. Tsirkin"
wrote:
> On Wed, Mar 22, 2023 at 11:40:56AM +0800, Xuan Zhuo wrote:
> > On Tue, 21 Mar 2023 23:34:43 -0400, "Michael S. Tsirkin"
> > wrote:
> > > On Wed, Mar 22, 2023 at 11:03:00AM +0800, Xuan Zhuo wrote:
> > > > Due to historical reasons
==
Call For Nominations: HPDC'23 Achievement Award
In 2012, HPDC established an annual achievement award, which is presented to an
individual who has made long-lasting, influential contributions to the
foundations or practice of the field of high-performance parallel and
distrib
79 matches
Mail list logo
