| Message ID | 1408369040-1216-3-git-send-email-pagupta@redhat.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: > This patch publishes maximum number of tun/tap queues allocated as a > read_only module parameter which a user space application like libvirt > can make use of to limit maximum number of queues. Value of read_only > module parameter can be writable only at module load time. If no value is set > at module load time a default value 256 is used which is equal to maximum number > of vCPUS allowed by KVM. > > Administrator can specify maximum number of queues only at the driver > module load time. > >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> >--- > drivers/net/tun.c | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > >diff --git a/drivers/net/tun.c b/drivers/net/tun.c >index acaaf67..1f518e2 100644 >--- a/drivers/net/tun.c >+++ b/drivers/net/tun.c >@@ -119,6 +119,9 @@ struct tap_filter { > > #define TUN_FLOW_EXPIRE (3 * HZ) > >+static int max_tap_queues = MAX_TAP_QUEUES; >+module_param(max_tap_queues, int, S_IRUGO); Please do not introduce new module paramaters. Please other ways to interchange values with userspace. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: > Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: > > This patch publishes maximum number of tun/tap queues allocated as a > > read_only module parameter which a user space application like libvirt > > can make use of to limit maximum number of queues. Value of read_only > > module parameter can be writable only at module load time. If no value is set > > at module load time a default value 256 is used which is equal to maximum number > > of vCPUS allowed by KVM. > > > > Administrator can specify maximum number of queues only at the driver > > module load time. > > > >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> > >--- > > drivers/net/tun.c | 13 +++++++++++-- > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > >diff --git a/drivers/net/tun.c b/drivers/net/tun.c > >index acaaf67..1f518e2 100644 > >--- a/drivers/net/tun.c > >+++ b/drivers/net/tun.c > >@@ -119,6 +119,9 @@ struct tap_filter { > > > > #define TUN_FLOW_EXPIRE (3 * HZ) > > > >+static int max_tap_queues = MAX_TAP_QUEUES; > >+module_param(max_tap_queues, int, S_IRUGO); > > Please do not introduce new module paramaters. Please other ways to > interchange values with userspace. I suggested this initially, but thinking more about it, I agree. It's a global limit (necessary to limit memory utilization by userspace), but it should be possible to change it after module load. Additionally, userspace that has the FD should be able to retrieve the value without guessing that the FD is for the tun device (and not e.g. macvtap). To retrieve the value, an ioctl is probably the cleanest approach. To set it, how about a sysctl? I think the limit can also apply to all devices, not just tun.
Wed, Aug 20, 2014 at 01:17:24PM CEST, mst@redhat.com wrote: >On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: >> Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: >> > This patch publishes maximum number of tun/tap queues allocated as a >> > read_only module parameter which a user space application like libvirt >> > can make use of to limit maximum number of queues. Value of read_only >> > module parameter can be writable only at module load time. If no value is set >> > at module load time a default value 256 is used which is equal to maximum number >> > of vCPUS allowed by KVM. >> > >> > Administrator can specify maximum number of queues only at the driver >> > module load time. >> > >> >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> >> >--- >> > drivers/net/tun.c | 13 +++++++++++-- >> > 1 files changed, 11 insertions(+), 2 deletions(-) >> > >> >diff --git a/drivers/net/tun.c b/drivers/net/tun.c >> >index acaaf67..1f518e2 100644 >> >--- a/drivers/net/tun.c >> >+++ b/drivers/net/tun.c >> >@@ -119,6 +119,9 @@ struct tap_filter { >> > >> > #define TUN_FLOW_EXPIRE (3 * HZ) >> > >> >+static int max_tap_queues = MAX_TAP_QUEUES; >> >+module_param(max_tap_queues, int, S_IRUGO); >> >> Please do not introduce new module paramaters. Please other ways to >> interchange values with userspace. > >I suggested this initially, but thinking more about it, I agree. > >It's a global limit (necessary to limit memory utilization by >userspace), but it should be possible to change it >after module load. > >Additionally, userspace that has the FD should be able to >retrieve the value without guessing that the FD is >for the tun device (and not e.g. macvtap). >To retrieve the value, an ioctl is probably the >cleanest approach. > >To set it, how about a sysctl? I think the limit can also apply to >all devices, not just tun. Or netlink? > >-- >MST -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 20, 2014 at 01:46:20PM +0200, Jiri Pirko wrote: > Wed, Aug 20, 2014 at 01:17:24PM CEST, mst@redhat.com wrote: > >On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: > >> Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: > >> > This patch publishes maximum number of tun/tap queues allocated as a > >> > read_only module parameter which a user space application like libvirt > >> > can make use of to limit maximum number of queues. Value of read_only > >> > module parameter can be writable only at module load time. If no value is set > >> > at module load time a default value 256 is used which is equal to maximum number > >> > of vCPUS allowed by KVM. > >> > > >> > Administrator can specify maximum number of queues only at the driver > >> > module load time. > >> > > >> >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> > >> >--- > >> > drivers/net/tun.c | 13 +++++++++++-- > >> > 1 files changed, 11 insertions(+), 2 deletions(-) > >> > > >> >diff --git a/drivers/net/tun.c b/drivers/net/tun.c > >> >index acaaf67..1f518e2 100644 > >> >--- a/drivers/net/tun.c > >> >+++ b/drivers/net/tun.c > >> >@@ -119,6 +119,9 @@ struct tap_filter { > >> > > >> > #define TUN_FLOW_EXPIRE (3 * HZ) > >> > > >> >+static int max_tap_queues = MAX_TAP_QUEUES; > >> >+module_param(max_tap_queues, int, S_IRUGO); > >> > >> Please do not introduce new module paramaters. Please other ways to > >> interchange values with userspace. > > > >I suggested this initially, but thinking more about it, I agree. > > > >It's a global limit (necessary to limit memory utilization by > >userspace), but it should be possible to change it > >after module load. > > > >Additionally, userspace that has the FD should be able to > >retrieve the value without guessing that the FD is > >for the tun device (and not e.g. macvtap). > >To retrieve the value, an ioctl is probably the > >cleanest approach. > > > >To set it, how about a sysctl? I think the limit can also apply to > >all devices, not just tun. > > Or netlink? Are there examples of netlink being used to set global defaults as opposed to per-device parameters? > > > >-- > >MST -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wed, Aug 20, 2014 at 01:49:07PM CEST, mst@redhat.com wrote: >On Wed, Aug 20, 2014 at 01:46:20PM +0200, Jiri Pirko wrote: >> Wed, Aug 20, 2014 at 01:17:24PM CEST, mst@redhat.com wrote: >> >On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: >> >> Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: >> >> > This patch publishes maximum number of tun/tap queues allocated as a >> >> > read_only module parameter which a user space application like libvirt >> >> > can make use of to limit maximum number of queues. Value of read_only >> >> > module parameter can be writable only at module load time. If no value is set >> >> > at module load time a default value 256 is used which is equal to maximum number >> >> > of vCPUS allowed by KVM. >> >> > >> >> > Administrator can specify maximum number of queues only at the driver >> >> > module load time. >> >> > >> >> >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> >> >> >--- >> >> > drivers/net/tun.c | 13 +++++++++++-- >> >> > 1 files changed, 11 insertions(+), 2 deletions(-) >> >> > >> >> >diff --git a/drivers/net/tun.c b/drivers/net/tun.c >> >> >index acaaf67..1f518e2 100644 >> >> >--- a/drivers/net/tun.c >> >> >+++ b/drivers/net/tun.c >> >> >@@ -119,6 +119,9 @@ struct tap_filter { >> >> > >> >> > #define TUN_FLOW_EXPIRE (3 * HZ) >> >> > >> >> >+static int max_tap_queues = MAX_TAP_QUEUES; >> >> >+module_param(max_tap_queues, int, S_IRUGO); >> >> >> >> Please do not introduce new module paramaters. Please other ways to >> >> interchange values with userspace. >> > >> >I suggested this initially, but thinking more about it, I agree. >> > >> >It's a global limit (necessary to limit memory utilization by >> >userspace), but it should be possible to change it >> >after module load. >> > >> >Additionally, userspace that has the FD should be able to >> >retrieve the value without guessing that the FD is >> >for the tun device (and not e.g. macvtap). >> >To retrieve the value, an ioctl is probably the >> >cleanest approach. >> > >> >To set it, how about a sysctl? I think the limit can also apply to >> >all devices, not just tun. >> >> Or netlink? > >Are there examples of netlink being used to set global defaults >as opposed to per-device parameters? That is so far not possible. But I believe that it can be implemented. I'm just thinking out loud. > >> > >> >-- >> >MST -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/20/2014 07:17 PM, Michael S. Tsirkin wrote: > On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: >> > Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: >>> > > This patch publishes maximum number of tun/tap queues allocated as a >>> > > read_only module parameter which a user space application like libvirt >>> > > can make use of to limit maximum number of queues. Value of read_only >>> > > module parameter can be writable only at module load time. If no value is set >>> > > at module load time a default value 256 is used which is equal to maximum number >>> > > of vCPUS allowed by KVM. >>> > > >>> > > Administrator can specify maximum number of queues only at the driver >>> > > module load time. >>> > > >>> > >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> >>> > >--- >>> > > drivers/net/tun.c | 13 +++++++++++-- >>> > > 1 files changed, 11 insertions(+), 2 deletions(-) >>> > > >>> > >diff --git a/drivers/net/tun.c b/drivers/net/tun.c >>> > >index acaaf67..1f518e2 100644 >>> > >--- a/drivers/net/tun.c >>> > >+++ b/drivers/net/tun.c >>> > >@@ -119,6 +119,9 @@ struct tap_filter { >>> > > >>> > > #define TUN_FLOW_EXPIRE (3 * HZ) >>> > > >>> > >+static int max_tap_queues = MAX_TAP_QUEUES; >>> > >+module_param(max_tap_queues, int, S_IRUGO); >> > >> > Please do not introduce new module paramaters. Please other ways to >> > interchange values with userspace. > I suggested this initially, but thinking more about it, I agree. > > It's a global limit (necessary to limit memory utilization by > userspace), but it should be possible to change it > after module load. How about pass this limit through ifr during TUNSETIFF, then alloc_netdev_mq() can use this limit. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > On 08/20/2014 07:17 PM, Michael S. Tsirkin wrote: > > On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: > >> > Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: > >>> > > This patch publishes maximum number of tun/tap queues allocated as a > >>> > > read_only module parameter which a user space application like > >>> > > libvirt > >>> > > can make use of to limit maximum number of queues. Value of read_only > >>> > > module parameter can be writable only at module load time. If no > >>> > > value is set > >>> > > at module load time a default value 256 is used which is equal to > >>> > > maximum number > >>> > > of vCPUS allowed by KVM. > >>> > > > >>> > > Administrator can specify maximum number of queues only at the driver > >>> > > module load time. > >>> > > > >>> > >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> > >>> > >--- > >>> > > drivers/net/tun.c | 13 +++++++++++-- > >>> > > 1 files changed, 11 insertions(+), 2 deletions(-) > >>> > > > >>> > >diff --git a/drivers/net/tun.c b/drivers/net/tun.c > >>> > >index acaaf67..1f518e2 100644 > >>> > >--- a/drivers/net/tun.c > >>> > >+++ b/drivers/net/tun.c > >>> > >@@ -119,6 +119,9 @@ struct tap_filter { > >>> > > > >>> > > #define TUN_FLOW_EXPIRE (3 * HZ) > >>> > > > >>> > >+static int max_tap_queues = MAX_TAP_QUEUES; > >>> > >+module_param(max_tap_queues, int, S_IRUGO); > >> > > >> > Please do not introduce new module paramaters. Please other ways to > >> > interchange values with userspace. > > I suggested this initially, but thinking more about it, I agree. > > > > It's a global limit (necessary to limit memory utilization by > > userspace), but it should be possible to change it > > after module load. > > How about pass this limit through ifr during TUNSETIFF, then > alloc_netdev_mq() can use this limit. Any other ideas/comments from the experts. Or shall I re-repost other patches in the series except this patch until we agree on one. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 22, 2014 at 07:52:22AM -0400, Pankaj Gupta wrote: > > > > > On 08/20/2014 07:17 PM, Michael S. Tsirkin wrote: > > > On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: > > >> > Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: > > >>> > > This patch publishes maximum number of tun/tap queues allocated as a > > >>> > > read_only module parameter which a user space application like > > >>> > > libvirt > > >>> > > can make use of to limit maximum number of queues. Value of read_only > > >>> > > module parameter can be writable only at module load time. If no > > >>> > > value is set > > >>> > > at module load time a default value 256 is used which is equal to > > >>> > > maximum number > > >>> > > of vCPUS allowed by KVM. > > >>> > > > > >>> > > Administrator can specify maximum number of queues only at the driver > > >>> > > module load time. > > >>> > > > > >>> > >Signed-off-by: Pankaj Gupta <pagupta@redhat.com> > > >>> > >--- > > >>> > > drivers/net/tun.c | 13 +++++++++++-- > > >>> > > 1 files changed, 11 insertions(+), 2 deletions(-) > > >>> > > > > >>> > >diff --git a/drivers/net/tun.c b/drivers/net/tun.c > > >>> > >index acaaf67..1f518e2 100644 > > >>> > >--- a/drivers/net/tun.c > > >>> > >+++ b/drivers/net/tun.c > > >>> > >@@ -119,6 +119,9 @@ struct tap_filter { > > >>> > > > > >>> > > #define TUN_FLOW_EXPIRE (3 * HZ) > > >>> > > > > >>> > >+static int max_tap_queues = MAX_TAP_QUEUES; > > >>> > >+module_param(max_tap_queues, int, S_IRUGO); > > >> > > > >> > Please do not introduce new module paramaters. Please other ways to > > >> > interchange values with userspace. > > > I suggested this initially, but thinking more about it, I agree. > > > > > > It's a global limit (necessary to limit memory utilization by > > > userspace), but it should be possible to change it > > > after module load. > > > > How about pass this limit through ifr during TUNSETIFF, then > > alloc_netdev_mq() can use this limit. > > Any other ideas/comments from the experts. Or shall I re-repost other patches > in the series except this patch until we agree on one. > > > It's kind of useless without a way for userspace to discover how many queues it can create, no? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/24/2014 07:14 PM, Michael S. Tsirkin wrote: > On Fri, Aug 22, 2014 at 07:52:22AM -0400, Pankaj Gupta wrote: >>> On 08/20/2014 07:17 PM, Michael S. Tsirkin wrote: >>>> On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: >>>>>> Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: >>>>>>>> This patch publishes maximum number of tun/tap queues allocated as a >>>>>>>> read_only module parameter which a user space application like >>>>>>>> libvirt >>>>>>>> can make use of to limit maximum number of queues. Value of read_only >>>>>>>> module parameter can be writable only at module load time. If no >>>>>>>> value is set >>>>>>>> at module load time a default value 256 is used which is equal to >>>>>>>> maximum number >>>>>>>> of vCPUS allowed by KVM. >>>>>>>> >>>>>>>> Administrator can specify maximum number of queues only at the driver >>>>>>>> module load time. >>>>>>>> >>>>>>>> Signed-off-by: Pankaj Gupta <pagupta@redhat.com> >>>>>>>> --- >>>>>>>> drivers/net/tun.c | 13 +++++++++++-- >>>>>>>> 1 files changed, 11 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c >>>>>>>> index acaaf67..1f518e2 100644 >>>>>>>> --- a/drivers/net/tun.c >>>>>>>> +++ b/drivers/net/tun.c >>>>>>>> @@ -119,6 +119,9 @@ struct tap_filter { >>>>>>>> >>>>>>>> #define TUN_FLOW_EXPIRE (3 * HZ) >>>>>>>> >>>>>>>> +static int max_tap_queues = MAX_TAP_QUEUES; >>>>>>>> +module_param(max_tap_queues, int, S_IRUGO); >>>>>> Please do not introduce new module paramaters. Please other ways to >>>>>> interchange values with userspace. >>>> I suggested this initially, but thinking more about it, I agree. >>>> >>>> It's a global limit (necessary to limit memory utilization by >>>> userspace), but it should be possible to change it >>>> after module load. >>> How about pass this limit through ifr during TUNSETIFF, then >>> alloc_netdev_mq() can use this limit. >> Any other ideas/comments from the experts. Or shall I re-repost other patches >> in the series except this patch until we agree on one. >> > It's kind of useless without a way for userspace to discover > how many queues it can create, no? > We can implement ethtool_get_channels for tuntap. But I'm still not clear why this is necessary. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On 08/24/2014 07:14 PM, Michael S. Tsirkin wrote: > > On Fri, Aug 22, 2014 at 07:52:22AM -0400, Pankaj Gupta wrote: > >>> On 08/20/2014 07:17 PM, Michael S. Tsirkin wrote: > >>>> On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote: > >>>>>> Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote: > >>>>>>>> This patch publishes maximum number of tun/tap queues allocated as a > >>>>>>>> read_only module parameter which a user space application like > >>>>>>>> libvirt > >>>>>>>> can make use of to limit maximum number of queues. Value of > >>>>>>>> read_only > >>>>>>>> module parameter can be writable only at module load time. If no > >>>>>>>> value is set > >>>>>>>> at module load time a default value 256 is used which is equal to > >>>>>>>> maximum number > >>>>>>>> of vCPUS allowed by KVM. > >>>>>>>> > >>>>>>>> Administrator can specify maximum number of queues only at the > >>>>>>>> driver > >>>>>>>> module load time. > >>>>>>>> > >>>>>>>> Signed-off-by: Pankaj Gupta <pagupta@redhat.com> > >>>>>>>> --- > >>>>>>>> drivers/net/tun.c | 13 +++++++++++-- > >>>>>>>> 1 files changed, 11 insertions(+), 2 deletions(-) > >>>>>>>> > >>>>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c > >>>>>>>> index acaaf67..1f518e2 100644 > >>>>>>>> --- a/drivers/net/tun.c > >>>>>>>> +++ b/drivers/net/tun.c > >>>>>>>> @@ -119,6 +119,9 @@ struct tap_filter { > >>>>>>>> > >>>>>>>> #define TUN_FLOW_EXPIRE (3 * HZ) > >>>>>>>> > >>>>>>>> +static int max_tap_queues = MAX_TAP_QUEUES; > >>>>>>>> +module_param(max_tap_queues, int, S_IRUGO); > >>>>>> Please do not introduce new module paramaters. Please other ways to > >>>>>> interchange values with userspace. > >>>> I suggested this initially, but thinking more about it, I agree. > >>>> > >>>> It's a global limit (necessary to limit memory utilization by > >>>> userspace), but it should be possible to change it > >>>> after module load. > >>> How about pass this limit through ifr during TUNSETIFF, then > >>> alloc_netdev_mq() can use this limit. > >> Any other ideas/comments from the experts. Or shall I re-repost other > >> patches > >> in the series except this patch until we agree on one. > >> > > It's kind of useless without a way for userspace to discover > > how many queues it can create, no? > > > > We can implement ethtool_get_channels for tuntap. But I'm still not > clear why this is necessary. ethtool_get_channels for tuntap sounds good idea to retrieve number of queues configured. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index acaaf67..1f518e2 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -119,6 +119,9 @@ struct tap_filter { #define TUN_FLOW_EXPIRE (3 * HZ) +static int max_tap_queues = MAX_TAP_QUEUES; +module_param(max_tap_queues, int, S_IRUGO); + /* A tun_file connects an open character device to a tuntap netdevice. It * also contains all socket related structures (except sock_fprog and tap_filter) * to serve as one transmit queue for tuntap device. The sock_fprog and @@ -545,7 +548,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file, bool skip_filte err = -E2BIG; if (!tfile->detached && - tun->numqueues + tun->numdisabled == MAX_TAP_QUEUES) + tun->numqueues + tun->numdisabled == max_tap_queues) goto out; err = 0; @@ -1609,7 +1612,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) char *name; unsigned long flags = 0; int queues = ifr->ifr_flags & IFF_MULTI_QUEUE ? - MAX_TAP_QUEUES : 1; + max_tap_queues : 1; if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) return -EPERM; @@ -2327,6 +2330,12 @@ static int __init tun_init(void) pr_info("%s, %s\n", DRV_DESCRIPTION, DRV_VERSION); pr_info("%s\n", DRV_COPYRIGHT); + if (max_tap_queues > MAX_TAP_QUEUES || max_tap_queues <= 0) { + printk(KERN_WARNING "max_tap_queues parameter value either too large" + " or too small forcing default value: %d\n", MAX_TAP_QUEUES); + max_tap_queues = MAX_TAP_QUEUES; + } + ret = rtnl_link_register(&tun_link_ops); if (ret) { pr_err("Can't register link_ops\n");
This patch publishes maximum number of tun/tap queues allocated as a read_only module parameter which a user space application like libvirt can make use of to limit maximum number of queues. Value of read_only module parameter can be writable only at module load time. If no value is set at module load time a default value 256 is used which is equal to maximum number of vCPUS allowed by KVM. Administrator can specify maximum number of queues only at the driver module load time. Signed-off-by: Pankaj Gupta <pagupta@redhat.com> --- drivers/net/tun.c | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-)