These are used to index aargument of IORING_REGISTER_IOWQ_MAX_WORKERS
io_uring_register command, so they are to be exposed in UAPI.
Signed-off-by: Eugene Syromiatnikov <[email protected]>
---
fs/io-wq.c | 7 +------
include/uapi/linux/io_uring.h | 8 ++++++++
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/io-wq.c b/fs/io-wq.c
index 6c55362..5e7cd7c 100644
--- a/fs/io-wq.c
+++ b/fs/io-wq.c
@@ -14,6 +14,7 @@
#include <linux/rculist_nulls.h>
#include <linux/cpu.h>
#include <linux/tracehook.h>
+#include <uapi/linux/io_uring.h>
#include "io-wq.h"
@@ -77,12 +78,6 @@ struct io_wqe_acct {
unsigned long flags;
};
-enum {
- IO_WQ_ACCT_BOUND,
- IO_WQ_ACCT_UNBOUND,
- IO_WQ_ACCT_NR,
-};
-
/*
* Per-node worker thread pool
*/
diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index 59ef351..d67a3cc 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -324,6 +324,14 @@ enum {
IORING_REGISTER_LAST
};
+/* io-wq worker limit categories */
+enum {
+ IO_WQ_ACCT_BOUND,
+ IO_WQ_ACCT_UNBOUND,
+
+ IO_WQ_ACCT_NR /* Non-UAPI */
+};
+
/* deprecated, see struct io_uring_rsrc_update */
struct io_uring_files_update {
__u32 offset;
--
2.1.4
On 9/12/21 6:24 AM, Eugene Syromiatnikov wrote:
> These are used to index aargument of IORING_REGISTER_IOWQ_MAX_WORKERS
> io_uring_register command, so they are to be exposed in UAPI.
Not sure that's necessary, as it's really just a boolean values - is
the worker type bounded or not. That said, not against making it
available for userspace, but definitely not IO_WQ_ACCT_NR. It
should probably just go in liburing, I guess.
--
Jens Axboe
On Sun, Sep 12, 2021 at 12:29:41PM -0600, Jens Axboe wrote:
> On 9/12/21 6:24 AM, Eugene Syromiatnikov wrote:
> > These are used to index aargument of IORING_REGISTER_IOWQ_MAX_WORKERS
> > io_uring_register command, so they are to be exposed in UAPI.
>
> Not sure that's necessary, as it's really just a boolean values - is
> the worker type bounded or not. That said, not against making it
> available for userspace, but definitely not IO_WQ_ACCT_NR. It
> should probably just go in liburing, I guess.
If IO_WQ_ACCT_* were just boolean values, no enum would have been
introduced in the first place. What's the benefit of hiding
the API in the implementation, or burying it inside liburing?
--
ldv
On 9/12/21 4:24 PM, Dmitry V. Levin wrote:
> On Sun, Sep 12, 2021 at 12:29:41PM -0600, Jens Axboe wrote:
>> On 9/12/21 6:24 AM, Eugene Syromiatnikov wrote:
>>> These are used to index aargument of IORING_REGISTER_IOWQ_MAX_WORKERS
>>> io_uring_register command, so they are to be exposed in UAPI.
>>
>> Not sure that's necessary, as it's really just a boolean values - is
>> the worker type bounded or not. That said, not against making it
>> available for userspace, but definitely not IO_WQ_ACCT_NR. It
>> should probably just go in liburing, I guess.
>
> If IO_WQ_ACCT_* were just boolean values, no enum would have been
> introduced in the first place. What's the benefit of hiding
> the API in the implementation, or burying it inside liburing?
Because it's easier to grok internally with an enum instead of
using 0/1. And you could argue that's the case too for an app,
and as I said, I'm not against making them exposed, but the _NR
part is strictly internal.
Just add separate defines or an enum in io_uring.h:
enum {
IO_WQ_BOUND,
IO_WQ_UNBOUND,
};
and be done with it.
--
Jens Axboe