Hey Or,
not any more, Andy and Tal made the mlx5 AM code a kernel library which is called DIM f4e5f0e MAINTAINERS: add entry for Dynamic Interrupt Moderation 6a8788f bnxt_en: add support for software dynamic interrupt moderation 8115b75 net/dim: use struct net_dim_sample as arg to net_dim 4c4dbb4 net/mlx5e: Move dynamic interrupt coalescing code to include/linux 9a31742 net/mlx5e: Change Mellanox references in DIM code b9c872f net/mlx5e: Move generic functions to new file f5e7f67 net/mlx5e: Move AM logic enums 138968e net/mlx5e: Remove rq references in mlx5e_rx_am f58ee09 net/mlx5e: Move interrupt moderation forward declarations 98dd1ed net/mlx5e: Move interrupt moderation structs to new file can you make use of that? cc-ing them in case you have questions/comments
Thanks a lot for the pointer, I'm not following net-next regularly. This seems to be a copy of the mlx5 code. So as mentioned in the cover letter, the implementation was inspired from the mlx5 driver as it had some of the abstraction properties I was aiming to achieve. What I didn't mention, was that I started from using the mlx5 implementation as is (slightly modified). Unfortunately in the workloads that I've tested, I was not able to get the am level to converge. So I went in a slightly different direction which gave me better results (although still not perfect and lightly tested). This led me to believe that mlx5 offered strategy might not suite storage I/O workloads (although I do acknowledge that I could be proven wrong here). For example, a design choice I took was that the moderation scheme would be more aggressive towards latency on the expense of throughput optimization since high end storage devices are often expected to meet strict latency requirements. Does that makes sense for network devices? I don't know. Another difference is that unlike net devices, storage I/O transactions usually look like request/response where the data transfer is offloaded by the controller/hba (net devices moderate on raw RX datagrams). Moreover, it might not be trivial to track the bytes/sec from a completion at all (might be embedded somewhere in the consumer context). So overall, at this point I'm a bit skeptical that it will makes sense to commonise the two implementations. I'd like to hear some more input if this is something that the community is interested in first. If this is something people are interested in, we can look if it makes sense to reuse net_dim.h or not. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
