Re: [PATCH V3 4/4] vdpa_sim_net: vendor satistics

2022-12-23 Thread Stefano Garzarella

On Fri, Dec 23, 2022 at 01:55:48PM +0800, Jason Wang wrote:

This patch adds support for basic vendor stats that include counters
for tx, rx and cvq.

Acked-by: Eugenio Pérez 
Signed-off-by: Jason Wang 
---
drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 219 ++-
1 file changed, 213 insertions(+), 6 deletions(-)


Little typo in the commit title s/satistics/statistics

Anyway, the patch LGTM:

Reviewed-by: Stefano Garzarella 



diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c 
b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
index 5abd4efd9028..e827708adcca 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
@@ -15,6 +15,7 @@
#include 
#include 
#include 
+#include 
#include 
#include 

@@ -37,6 +38,34 @@
#define VDPASIM_NET_AS_NUM  2
#define VDPASIM_NET_GROUP_NUM   2

+struct vdpasim_dataq_stats {
+   struct u64_stats_sync syncp;
+   u64 pkts;
+   u64 bytes;
+   u64 drops;
+   u64 errors;
+   u64 overruns;
+};
+
+struct vdpasim_cq_stats {
+   struct u64_stats_sync syncp;
+   u64 requests;
+   u64 successes;
+   u64 errors;
+};
+
+struct vdpasim_net{
+   struct vdpasim vdpasim;
+   struct vdpasim_dataq_stats tx_stats;
+   struct vdpasim_dataq_stats rx_stats;
+   struct vdpasim_cq_stats cq_stats;
+};
+
+static struct vdpasim_net *sim_to_net(struct vdpasim *vdpasim)
+{
+   return container_of(vdpasim, struct vdpasim_net, vdpasim);
+}
+
static void vdpasim_net_complete(struct vdpasim_virtqueue *vq, size_t len)
{
/* Make sure data is wrote before advancing index */
@@ -97,9 +126,11 @@ static virtio_net_ctrl_ack vdpasim_handle_ctrl_mac(struct 
vdpasim *vdpasim,
static void vdpasim_handle_cvq(struct vdpasim *vdpasim)
{
struct vdpasim_virtqueue *cvq = >vqs[2];
+   struct vdpasim_net *net = sim_to_net(vdpasim);
virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
struct virtio_net_ctrl_hdr ctrl;
size_t read, write;
+   u64 requests = 0, errors = 0, successes = 0;
int err;

if (!(vdpasim->features & (1ULL << VIRTIO_NET_F_CTRL_VQ)))
@@ -115,10 +146,13 @@ static void vdpasim_handle_cvq(struct vdpasim *vdpasim)
if (err <= 0)
break;

+   ++requests;
read = vringh_iov_pull_iotlb(>vring, >in_iov, ,
 sizeof(ctrl));
-   if (read != sizeof(ctrl))
+   if (read != sizeof(ctrl)) {
+   ++errors;
break;
+   }

switch (ctrl.class) {
case VIRTIO_NET_CTRL_MAC:
@@ -128,6 +162,11 @@ static void vdpasim_handle_cvq(struct vdpasim *vdpasim)
break;
}

+   if (status == VIRTIO_NET_OK)
+   ++successes;
+   else
+   ++errors;
+
/* Make sure data is wrote before advancing index */
smp_wmb();

@@ -145,6 +184,12 @@ static void vdpasim_handle_cvq(struct vdpasim *vdpasim)
cvq->cb(cvq->private);
local_bh_enable();
}
+
+   u64_stats_update_begin(>cq_stats.syncp);
+   net->cq_stats.requests += requests;
+   net->cq_stats.errors += errors;
+   net->cq_stats.successes += successes;
+   u64_stats_update_end(>cq_stats.syncp);
}

static void vdpasim_net_work(struct work_struct *work)
@@ -152,8 +197,10 @@ static void vdpasim_net_work(struct work_struct *work)
struct vdpasim *vdpasim = container_of(work, struct vdpasim, work);
struct vdpasim_virtqueue *txq = >vqs[1];
struct vdpasim_virtqueue *rxq = >vqs[0];
+   struct vdpasim_net *net = sim_to_net(vdpasim);
ssize_t read, write;
-   int pkts = 0;
+   u64 tx_pkts = 0, rx_pkts = 0, tx_bytes = 0, rx_bytes = 0;
+   u64 rx_drops = 0, rx_overruns = 0, rx_errors = 0, tx_errors = 0;
int err;

spin_lock(>lock);
@@ -172,14 +219,21 @@ static void vdpasim_net_work(struct work_struct *work)
while (true) {
err = vringh_getdesc_iotlb(>vring, >out_iov, NULL,
   >head, GFP_ATOMIC);
-   if (err <= 0)
+   if (err <= 0) {
+   if (err)
+   ++tx_errors;
break;
+   }

+   ++tx_pkts;
read = vringh_iov_pull_iotlb(>vring, >out_iov,
 vdpasim->buffer,
 PAGE_SIZE);

+   tx_bytes += read;
+
if (!receive_filter(vdpasim, read)) {
+   ++rx_drops;
vdpasim_net_complete(txq, 0);
continue;
}
@@ -187,19 +241,25 @@ static void vdpasim_net_work(struct work_struct *work)
err = 

Re: [PATCH] virtio_balloon: high order allocation

2022-12-23 Thread David Hildenbrand

On 23.12.22 10:35, Soichiro Ueda wrote:

At present, the VirtIO balloon device driver allocates pages
one by one using alloc_page(), and frees them using put_page().

This changes it so that the driver allocates high order pages
by using alloc_pages(), and frees them using __free_pages() if possible.
By doing so, the CPU performance of inflation and deflation
should be improved.

The effect of this change has been confirmed by benchmarks that measure
the elapsed time of inflation and deflation.

The results are here:

16 pages inflation:
   before: 119,779 ns
   after : 115,655 ns (-3.4%)
64 pages inflation:
   before: 156,977 ns
   after : 150,961 ns (-3.8%)
256 pages inflation:
   before: 218,649 ns
   after : 208,490 ns (-4.6%)
16 pages deflation:
   before: 78,112 ns
   after : 68,288 ns (-12.6%)
64 pages deflation:
   before: 97,205 ns
   after : 80,491 ns (-17.194%)
256 pages deflation:
   before: 122,742 ns
   after : 107,526 ns (-12.4%)


How does this affect page migration / balloon compaction etc?

--
Thanks,

David / dhildenb

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH V3 3/4] vdpa_sim: support vendor statistics

2022-12-23 Thread Stefano Garzarella

On Fri, Dec 23, 2022 at 01:55:47PM +0800, Jason Wang wrote:

This patch adds a new config ops callback to allow individual
simulator to implement the vendor stats callback.

Acked-by: Eugenio Pérez 
Signed-off-by: Jason Wang 
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 14 ++
drivers/vdpa/vdpa_sim/vdpa_sim.h |  3 +++
2 files changed, 17 insertions(+)


Reviewed-by: Stefano Garzarella 



diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 341da107e7da..45d3f84b7937 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -424,6 +424,18 @@ static int vdpasim_get_vq_state(struct vdpa_device *vdpa, 
u16 idx,
return 0;
}

+static int vdpasim_get_vq_stats(struct vdpa_device *vdpa, u16 idx,
+   struct sk_buff *msg,
+   struct netlink_ext_ack *extack)
+{
+   struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
+
+   if (vdpasim->dev_attr.get_stats)
+   return vdpasim->dev_attr.get_stats(vdpasim, idx,
+  msg, extack);
+   return -EOPNOTSUPP;
+}
+
static u32 vdpasim_get_vq_align(struct vdpa_device *vdpa)
{
return VDPASIM_QUEUE_ALIGN;
@@ -710,6 +722,7 @@ static const struct vdpa_config_ops vdpasim_config_ops = {
.set_vq_ready   = vdpasim_set_vq_ready,
.get_vq_ready   = vdpasim_get_vq_ready,
.set_vq_state   = vdpasim_set_vq_state,
+   .get_vendor_vq_stats= vdpasim_get_vq_stats,
.get_vq_state   = vdpasim_get_vq_state,
.get_vq_align   = vdpasim_get_vq_align,
.get_vq_group   = vdpasim_get_vq_group,
@@ -743,6 +756,7 @@ static const struct vdpa_config_ops 
vdpasim_batch_config_ops = {
.set_vq_ready   = vdpasim_set_vq_ready,
.get_vq_ready   = vdpasim_get_vq_ready,
.set_vq_state   = vdpasim_set_vq_state,
+   .get_vendor_vq_stats= vdpasim_get_vq_stats,
.get_vq_state   = vdpasim_get_vq_state,
.get_vq_align   = vdpasim_get_vq_align,
.get_vq_group   = vdpasim_get_vq_group,
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h
index 51c070a543f1..d2a08c0abad7 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.h
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h
@@ -48,6 +48,9 @@ struct vdpasim_dev_attr {
work_func_t work_fn;
void (*get_config)(struct vdpasim *vdpasim, void *config);
void (*set_config)(struct vdpasim *vdpasim, const void *config);
+   int (*get_stats)(struct vdpasim *vdpasim, u16 idx,
+struct sk_buff *msg,
+struct netlink_ext_ack *extack);
};

/* State of each vdpasim device */
--
2.25.1



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH] vdpa_sim: get rid of DMA ops

2022-12-23 Thread Stefano Garzarella

On Fri, Dec 23, 2022 at 02:00:21PM +0800, Jason Wang wrote:

We used to (ab)use the DMA ops for setting up identical mappings in
the IOTLB. This patch tries to get rid of the those unnecessary DMA
ops by maintaining a simple identical/passthrough mappings by
default. When bound to virtio_vdpa driver, DMA API will simply use PA
as the IOVA and we will be all fine. When the vDPA bus tries to setup
customized mapping (e.g when bound to vhost-vDPA), the
identical/passthrough mapping will be removed.

Signed-off-by: Jason Wang 
---
Note:
- This patch depends on the series "[PATCH V3 0/4] Vendor stats
 support in vdpasim_net"
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 170 ---
drivers/vdpa/vdpa_sim/vdpa_sim.h |   2 +-
2 files changed, 22 insertions(+), 150 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 45d3f84b7937..187fa3a0e5d5 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -17,7 +17,6 @@
#include 
#include 
#include 
-#include 
#include 

#include "vdpa_sim.h"
@@ -45,13 +44,6 @@ static struct vdpasim *vdpa_to_sim(struct vdpa_device *vdpa)
return container_of(vdpa, struct vdpasim, vdpa);
}

-static struct vdpasim *dev_to_sim(struct device *dev)
-{
-   struct vdpa_device *vdpa = dev_to_vdpa(dev);
-
-   return vdpa_to_sim(vdpa);
-}
-
static void vdpasim_vq_notify(struct vringh *vring)
{
struct vdpasim_virtqueue *vq =
@@ -104,8 +96,12 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim)
 >iommu_lock);
}

-   for (i = 0; i < vdpasim->dev_attr.nas; i++)
+   for (i = 0; i < vdpasim->dev_attr.nas; i++) {
vhost_iotlb_reset(>iommu[i]);
+   vhost_iotlb_add_range(>iommu[i], 0, ULONG_MAX,
+ 0, VHOST_MAP_RW);
+   vdpasim->iommu_pt[i] = true;
+   }

vdpasim->running = true;
spin_unlock(>iommu_lock);
@@ -115,133 +111,6 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim)
++vdpasim->generation;
}

-static int dir_to_perm(enum dma_data_direction dir)
-{
-   int perm = -EFAULT;
-
-   switch (dir) {
-   case DMA_FROM_DEVICE:
-   perm = VHOST_MAP_WO;
-   break;
-   case DMA_TO_DEVICE:
-   perm = VHOST_MAP_RO;
-   break;
-   case DMA_BIDIRECTIONAL:
-   perm = VHOST_MAP_RW;
-   break;
-   default:
-   break;
-   }
-
-   return perm;
-}
-
-static dma_addr_t vdpasim_map_range(struct vdpasim *vdpasim, phys_addr_t paddr,
-   size_t size, unsigned int perm)
-{
-   struct iova *iova;
-   dma_addr_t dma_addr;
-   int ret;
-
-   /* We set the limit_pfn to the maximum (ULONG_MAX - 1) */
-   iova = alloc_iova(>iova, size >> iova_shift(>iova),
- ULONG_MAX - 1, true);
-   if (!iova)
-   return DMA_MAPPING_ERROR;
-
-   dma_addr = iova_dma_addr(>iova, iova);
-
-   spin_lock(>iommu_lock);
-   ret = vhost_iotlb_add_range(>iommu[0], (u64)dma_addr,
-   (u64)dma_addr + size - 1, (u64)paddr, perm);
-   spin_unlock(>iommu_lock);
-
-   if (ret) {
-   __free_iova(>iova, iova);
-   return DMA_MAPPING_ERROR;
-   }
-
-   return dma_addr;
-}
-
-static void vdpasim_unmap_range(struct vdpasim *vdpasim, dma_addr_t dma_addr,
-   size_t size)
-{
-   spin_lock(>iommu_lock);
-   vhost_iotlb_del_range(>iommu[0], (u64)dma_addr,
- (u64)dma_addr + size - 1);
-   spin_unlock(>iommu_lock);
-
-   free_iova(>iova, iova_pfn(>iova, dma_addr));
-}
-
-static dma_addr_t vdpasim_map_page(struct device *dev, struct page *page,
-  unsigned long offset, size_t size,
-  enum dma_data_direction dir,
-  unsigned long attrs)
-{
-   struct vdpasim *vdpasim = dev_to_sim(dev);
-   phys_addr_t paddr = page_to_phys(page) + offset;
-   int perm = dir_to_perm(dir);
-
-   if (perm < 0)
-   return DMA_MAPPING_ERROR;
-
-   return vdpasim_map_range(vdpasim, paddr, size, perm);
-}
-
-static void vdpasim_unmap_page(struct device *dev, dma_addr_t dma_addr,
-  size_t size, enum dma_data_direction dir,
-  unsigned long attrs)
-{
-   struct vdpasim *vdpasim = dev_to_sim(dev);
-
-   vdpasim_unmap_range(vdpasim, dma_addr, size);
-}
-
-static void *vdpasim_alloc_coherent(struct device *dev, size_t size,
-   dma_addr_t *dma_addr, gfp_t flag,
-   unsigned long attrs)
-{
-   struct vdpasim *vdpasim = dev_to_sim(dev);
-   phys_addr_t paddr;
-   void *addr;
-
-   addr = kmalloc(size, 

Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

2022-12-23 Thread Linus Torvalds
On Fri, Dec 23, 2022 at 2:27 PM Michael S. Tsirkin  wrote:
>
> They were all there, just not as these commits, as I squashed fixups to
> avoid bisect breakages with some configs. Did I do wrong?

I am literally looking at the next-20221214 state right now, doing

git log linus/master.. -- drivers/vhost/vsock.c
git log linus/master.. -- drivers/vdpa/mlx5/
git log --grep="temporary variable type tweak"

and seeing nothing.

So none of these commits - in *any* form - were in linux-next last
week as far as I can tell.

 Linus
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

2022-12-23 Thread Linus Torvalds
On Thu, Dec 22, 2022 at 11:43 AM Michael S. Tsirkin  wrote:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

I see none of this in linux-next.

   Linus
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

2022-12-23 Thread Michael S. Tsirkin
On Fri, Dec 23, 2022 at 05:27:49PM -0500, Michael S. Tsirkin wrote:
> On Fri, Dec 23, 2022 at 11:54:41AM -0800, Linus Torvalds wrote:
> > On Thu, Dec 22, 2022 at 11:43 AM Michael S. Tsirkin  wrote:
> > >
> > >   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
> > > tags/for_linus
> > 
> > I see none of this in linux-next.
> > 
> >Linus
> 
> They were all there, just not as these commits, as I squashed fixups to
> avoid bisect breakages with some configs. Did I do wrong?

More specifically, everything up to
458326ec10d1233399a342263d33878cb0afe710 lines up in next-20221220, and
then I decided to rebase to squash bugfixes.
Plus these are two trivial patches on top that just tweak sparse
tags so 0 chance of regressions, and an also trivial security-related bugfix.


> -- 
> MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

2022-12-23 Thread Michael S. Tsirkin
On Fri, Dec 23, 2022 at 11:54:41AM -0800, Linus Torvalds wrote:
> On Thu, Dec 22, 2022 at 11:43 AM Michael S. Tsirkin  wrote:
> >
> >   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
> > tags/for_linus
> 
> I see none of this in linux-next.
> 
>Linus

They were all there, just not as these commits, as I squashed fixups to
avoid bisect breakages with some configs. Did I do wrong?

-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

2022-12-23 Thread Linus Torvalds
On Fri, Dec 23, 2022 at 9:35 PM Michael S. Tsirkin  wrote:
>
> They were in  next-20221220 though.

So, perfect for the *next* merge window.

Do you understand what the word "next" means? We don't call it
"linux-this", do we?

This is not a new rule. Things are supposed to be ready *before* the
merge window (that's what makes it "next", get it?).

I will also point you to to

  
https://lore.kernel.org/lkml/CAHk-=wj_hcgfznyzhtlj7qc2613zphkdtlh6ndciwopzrfh...@mail.gmail.com/

where I'm being pretty damn clear about things.

And before you start bleating about "I needed more heads up", never
mind that this isn't even a new rule, and never mind what that "next"
word means, let me just point to the 6.1-rc6 notice too:

  
https://lore.kernel.org/lkml/CAHk-=wguzwx8sbb8zvm7fxwvfx6cgue7x+e16vkoql7ok9v...@mail.gmail.com/

and if the meaning of "next" has eluded you all these years, maybe it
was high time you learnt. Hmm?

  Linus
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

2022-12-23 Thread Michael S. Tsirkin
On Fri, Dec 23, 2022 at 02:36:46PM -0800, Linus Torvalds wrote:
> On Fri, Dec 23, 2022 at 2:27 PM Michael S. Tsirkin  wrote:
> >
> > They were all there, just not as these commits, as I squashed fixups to
> > avoid bisect breakages with some configs. Did I do wrong?
> 
> I am literally looking at the next-20221214 state right now, doing
> 
> git log linus/master.. -- drivers/vhost/vsock.c
> git log linus/master.. -- drivers/vdpa/mlx5/
> git log --grep="temporary variable type tweak"
> 
> and seeing nothing.
> 
> So none of these commits - in *any* form - were in linux-next last
> week as far as I can tell.
> 
>  Linus


They were in  next-20221220 though.

-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization