From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Joe Damato <jdamato@fastly.com>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
chuck.lever@oracle.com, jlayton@kernel.org,
linux-api@vger.kernel.org, brauner@kernel.org,
edumazet@google.com, davem@davemloft.net,
alexander.duyck@gmail.com, sridhar.samudrala@intel.com,
kuba@kernel.org, weiwan@google.com
Subject: Re: [net-next v2 3/4] eventpoll: Add epoll ioctl for epoll_params
Date: Thu, 25 Jan 2024 09:11:22 -0500 [thread overview]
Message-ID: <65b26c0ada0c6_2b890a294ef@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <20240125042746.GA1294@fastly.com>
Joe Damato wrote:
> On Wed, Jan 24, 2024 at 09:46:23PM -0500, Willem de Bruijn wrote:
> > Joe Damato wrote:
> > > Add an ioctl for getting and setting epoll_params. User programs can use
> > > this ioctl to get and set the busy poll usec time or packet budget
> > > params for a specific epoll context.
> > >
> > > Signed-off-by: Joe Damato <jdamato@fastly.com>
> >
> > Please be sure to include the lists and people suggested by
> > `get_maintainer.pl -f fs/eventpoll.c`.
>
> Thanks - I must have done something wrong when trying to get the maintainer
> list.
>
> Should I resend this v2? Not sure what the appropriate thing to do is in
> this case. My apologies.
If you don't get additional feedback in a few days and still prefer
this option that might be an approach.
After reading the below thread, compare the different possible APIs
and either revise the code or perhaps add a small paragraph why you
think this is the preferred path.
> > Adding ioctls is generally discouraged.
> >
> > As this affects the behavior of epoll_wait, should this just be a
> > flag to (a new variant of) epoll_wait?
>
> I have no strong preference either way. It seems to me that adding a new
> system call is a fairly significant change vs adding an ioctl, but I am
> open to whatever is preferred by the maintainers.
>
> I have no idea who would need to weigh-in to make this decision.
>
> > Speaking from some experience with adding epoll_pwait2. I initially
> > there added a stateful change that would affect wait behavior. The
> > sensible feedback as the time was to just change the behavior of the
> > syscall it affected. Even if that requires a syscall (which is not
> > that different from an ioctl, if better defined).
> >
> > The discussion in that thread may be informative to decide on API:
> > https://lwn.net/ml/linux-kernel/20201116161001.1606608-1-willemdebruijn.kernel@gmail.com/
>
> Interesting thread, thanks for sending.
>
> > Agreed on the overall principle that it is preferable to be able to
> > enable busypolling selectively. We already do for SO_BUSY_POLL and
> > sysctl busy_read.
>
> Thanks for taking a look and providing feedback.
>
> >
> > > ---
> > > .../userspace-api/ioctl/ioctl-number.rst | 1 +
> > > fs/eventpoll.c | 47 +++++++++++++++++++
> > > include/uapi/linux/eventpoll.h | 12 +++++
> > > 3 files changed, 60 insertions(+)
> > >
> > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > > index 457e16f06e04..b33918232f78 100644
> > > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> > > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > > @@ -309,6 +309,7 @@ Code Seq# Include File Comments
> > > 0x89 0B-DF linux/sockios.h
> > > 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
> > > 0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
> > > +0x8A 00-1F linux/eventpoll.h
> > > 0x8B all linux/wireless.h
> > > 0x8C 00-3F WiNRADiO driver
> > > <http://www.winradio.com.au/>
> > > diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> > > index 40bd97477b91..c1ee0fe01da1 100644
> > > --- a/fs/eventpoll.c
> > > +++ b/fs/eventpoll.c
> > > @@ -6,6 +6,8 @@
> > > * Davide Libenzi <davidel@xmailserver.org>
> > > */
> > >
> > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > +
> > > #include <linux/init.h>
> > > #include <linux/kernel.h>
> > > #include <linux/sched/signal.h>
> > > @@ -869,6 +871,49 @@ static void ep_clear_and_put(struct eventpoll *ep)
> > > ep_free(ep);
> > > }
> > >
> > > +static long ep_eventpoll_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> > > +{
> > > + int ret;
> > > + struct eventpoll *ep;
> > > + struct epoll_params epoll_params;
> > > + void __user *uarg = (void __user *) arg;
> > > +
> > > + if (!is_file_epoll(file))
> > > + return -EINVAL;
> > > +
> > > + ep = file->private_data;
> > > +
> > > + switch (cmd) {
> > > +#ifdef CONFIG_NET_RX_BUSY_POLL
> > > + case EPIOCSPARAMS:
> > > + if (copy_from_user(&epoll_params, uarg, sizeof(epoll_params)))
> > > + return -EFAULT;
> > > +
> > > + if (epoll_params.busy_poll_budget > NAPI_POLL_WEIGHT)
> > > + pr_err("busy poll budget %u exceeds suggested maximum %u\n",
> > > + epoll_params.busy_poll_budget, NAPI_POLL_WEIGHT);
> > > +
> > > + ep->busy_poll_usecs = epoll_params.busy_poll_usecs;
> > > + ep->busy_poll_budget = epoll_params.busy_poll_budget;
> > > + return 0;
> > > +
> > > + case EPIOCGPARAMS:
> > > + memset(&epoll_params, 0, sizeof(epoll_params));
> > > + epoll_params.busy_poll_usecs = ep->busy_poll_usecs;
> > > + epoll_params.busy_poll_budget = ep->busy_poll_budget;
> > > + if (copy_to_user(uarg, &epoll_params, sizeof(epoll_params)))
> > > + return -EFAULT;
> > > +
> > > + return 0;
> > > +#endif
> > > + default:
> > > + ret = -EINVAL;
> > > + break;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > static int ep_eventpoll_release(struct inode *inode, struct file *file)
> > > {
> > > struct eventpoll *ep = file->private_data;
> > > @@ -975,6 +1020,8 @@ static const struct file_operations eventpoll_fops = {
> > > .release = ep_eventpoll_release,
> > > .poll = ep_eventpoll_poll,
> > > .llseek = noop_llseek,
> > > + .unlocked_ioctl = ep_eventpoll_ioctl,
> > > + .compat_ioctl = compat_ptr_ioctl,
> > > };
> > >
> > > /*
> > > diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
> > > index cfbcc4cc49ac..8eb0fdbce995 100644
> > > --- a/include/uapi/linux/eventpoll.h
> > > +++ b/include/uapi/linux/eventpoll.h
> > > @@ -85,4 +85,16 @@ struct epoll_event {
> > > __u64 data;
> > > } EPOLL_PACKED;
> > >
> > > +struct epoll_params {
> > > + u64 busy_poll_usecs;
> > > + u16 busy_poll_budget;
> > > +
> > > + /* for future fields */
> > > + u8 data[118];
> > > +} EPOLL_PACKED;
> > > +
> > > +#define EPOLL_IOC_TYPE 0x8A
> > > +#define EPIOCSPARAMS _IOW(EPOLL_IOC_TYPE, 0x01, struct epoll_params)
> > > +#define EPIOCGPARAMS _IOR(EPOLL_IOC_TYPE, 0x02, struct epoll_params)
> > > +
> > > #endif /* _UAPI_LINUX_EVENTPOLL_H */
> > > --
> > > 2.25.1
> > >
> >
> >
next prev parent reply other threads:[~2024-01-25 14:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 0:30 [net-next v2 0/4] Per epoll context busy poll support Joe Damato
2024-01-25 0:30 ` [net-next v2 1/4] eventpoll: support busy poll per epoll instance Joe Damato
2024-01-25 0:30 ` [net-next v2 2/4] eventpoll: Add per-epoll busy poll packet budget Joe Damato
2024-01-25 0:30 ` [net-next v2 3/4] eventpoll: Add epoll ioctl for epoll_params Joe Damato
2024-01-25 2:46 ` Willem de Bruijn
2024-01-25 4:27 ` Joe Damato
2024-01-25 14:11 ` Willem de Bruijn [this message]
2024-01-25 13:12 ` kernel test robot
2024-01-25 0:30 ` [net-next v2 4/4] net: print error if SO_BUSY_POLL_BUDGET is large Joe Damato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65b26c0ada0c6_2b890a294ef@willemb.c.googlers.com.notmuch \
--to=willemdebruijn.kernel@gmail.com \
--cc=alexander.duyck@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jdamato@fastly.com \
--cc=jlayton@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sridhar.samudrala@intel.com \
--cc=weiwan@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).