From: Phil Sutter <phil@nwl.cc>
To: Or Gerlitz <gerlitz.or@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>,
Sabrina Dubroca <sd@queasysnail.net>
Subject: Re: [net-next PATCH v2] net: dummy: Introduce dummy virtual functions
Date: Fri, 18 Nov 2016 16:59:47 +0100 [thread overview]
Message-ID: <20161118155947.GB26542@orbyte.nwl.cc> (raw)
In-Reply-To: <CAJ3xEMhG4Eeh6pwY2Uq_KxmuHJb9-xYYkr4Ps_kQWwEXeB9Sbg@mail.gmail.com>
Hi,
On Fri, Nov 18, 2016 at 12:04:14AM +0200, Or Gerlitz wrote:
> On Mon, Nov 14, 2016 at 3:02 PM, Phil Sutter <phil@nwl.cc> wrote:
>
> > Due to the assumption that all PFs are PCI devices, this implementation
> > is not completely straightforward: In order to allow for
> > rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> > attached to the dummy netdev. This has to happen at the right spot so
> > register_netdevice() does not get confused. This patch abuses
> > ndo_fix_features callback for that. In ndo_uninit callback, the fake
> > parent is removed again for the same purpose.
>
> So you did some mimic-ing of PCI interface, how do you let the user to
> config the number of VFs? though a module param? why? if the module
> param only serves to say how many VF the device supports, maybe
> support the maximum possible by PCI spec and skip the module param?
Yes, this is controlled via module parameter. But it doesn't say how
much is supported but rather how many dummy VFs are to be created for
each dummy interface.
> > +module_param(num_vfs, int, 0);
> > +MODULE_PARM_DESC(num_vfs, "Number of dummy VFs per dummy device");
> > +
>
> > @@ -190,6 +382,7 @@ static int __init dummy_init_one(void)
> > err = register_netdevice(dev_dummy);
> > if (err < 0)
> > goto err;
> > +
> > return 0;
>
> nit, remove this added blank line..
Oh yes, thanks. Spontaneous reviewer's blindness. :)
The implementation is problematic in another aspect though: Upon reboot,
it seems like no netdev ops are being called but the fake PCI parent's
kobject is being freed which does not work (and leads to an oops).
Cheers, Phil
prev parent reply other threads:[~2016-11-18 15:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 13:02 [net-next PATCH v2] net: dummy: Introduce dummy virtual functions Phil Sutter
2016-11-14 14:23 ` Eric Dumazet
2016-11-17 22:04 ` Or Gerlitz
2016-11-18 15:59 ` Phil Sutter [this message]
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=20161118155947.GB26542@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=davem@davemloft.net \
--cc=gerlitz.or@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.