From: Jiri Pirko <jiri@resnulli.us>
To: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Cc: mst@redhat.com, stephen@networkplumber.org, davem@davemloft.net,
netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org, jesse.brandeburg@intel.com,
alexander.h.duyck@intel.com, kubakici@wp.pl, jasowang@redhat.com,
loseweigh@gmail.com
Subject: Re: [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available
Date: Tue, 10 Apr 2018 17:43:04 +0200 [thread overview]
Message-ID: <20180410154304.GG2028@nanopsycho> (raw)
In-Reply-To: <d08ed1e6-678a-7b34-cd2e-52788ceec919@intel.com>
Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala@intel.com wrote:
>On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala@intel.com wrote:
>> > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>> > > Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala@intel.com wrote:
>> > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala@intel.com wrote:
>> > > > > > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> > > > > > > Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala@intel.com wrote:
>> > > > > [...]
>> > > > >
>> > > > > > > > +static int virtnet_bypass_join_child(struct net_device *bypass_netdev,
>> > > > > > > > + struct net_device *child_netdev)
>> > > > > > > > +{
>> > > > > > > > + struct virtnet_bypass_info *vbi;
>> > > > > > > > + bool backup;
>> > > > > > > > +
>> > > > > > > > + vbi = netdev_priv(bypass_netdev);
>> > > > > > > > + backup = (child_netdev->dev.parent == bypass_netdev->dev.parent);
>> > > > > > > > + if (backup ? rtnl_dereference(vbi->backup_netdev) :
>> > > > > > > > + rtnl_dereference(vbi->active_netdev)) {
>> > > > > > > > + netdev_info(bypass_netdev,
>> > > > > > > > + "%s attempting to join bypass dev when %s already present\n",
>> > > > > > > > + child_netdev->name, backup ? "backup" : "active");
>> > > > > > > Bypass module should check if there is already some other netdev
>> > > > > > > enslaved and refuse right there.
>> > > > > > This will work for virtio-net with 3 netdev model, but this check has to be done by netvsc
>> > > > > > as its bypass_netdev is same as the backup_netdev.
>> > > > > > Will add a flag while registering with the bypass module to indicate if the driver is doing
>> > > > > > a 2 netdev or 3 netdev model and based on that flag this check can be done in bypass module
>> > > > > > for 3 netdev scenario.
>> > > > > Just let me undestand it clearly. What I expect the difference would be
>> > > > > between 2netdev and3 netdev model is this:
>> > > > > 2netdev:
>> > > > > bypass_master
>> > > > > /
>> > > > > /
>> > > > > VF_slave
>> > > > >
>> > > > > 3netdev:
>> > > > > bypass_master
>> > > > > / \
>> > > > > / \
>> > > > > VF_slave backup_slave
>> > > > >
>> > > > > Is that correct? If not, how does it look like?
>> > > > >
>> > > > >
>> > > > Looks correct.
>> > > > VF_slave and backup_slave are the original netdevs and are present in both the models.
>> > > > In the 3 netdev model, bypass_master netdev is created and VF_slave and backup_slave are
>> > > > marked as the 2 slaves of this new netdev.
>> > > You say it looks correct and in another sentence you provide completely
>> > > different description. Could you please look again?
>> > >
>> > To be exact, 2 netdev model with netvsc looks like this.
>> >
>> > netvsc_netdev
>> > /
>> > /
>> > VF_slave
>> >
>> > With virtio_net, 3 netdev model
>> >
>> > bypass_netdev
>> > / \
>> > / \
>> > VF_slave virtio_net netdev
>> Could you also mark the original netdev which is there now? is it
>> bypass_netdev or virtio_net_netdev ?
>
> bypass_netdev
> / \
> / \
>VF_slave virtio_net netdev (original)
That does not make sense.
1) You diverge from the behaviour of the netvsc, where the original
netdev is a master of the VF
2) If the original netdev is a slave, you cannot have any IP address
configured on it (well you could, but the rx_handler would eat every
incoming packet). So you will break the user bacause he would have to
move the configuration to the new master device.
This only makes sense that the original netdev becomes the master for both
netvsc and virtio_net.
next prev parent reply other threads:[~2018-04-10 15:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-05 21:08 [RFC PATCH net-next v5 0/4] Enable virtio_net to act as a backup for a passthru device Sridhar Samudrala
2018-04-05 21:08 ` [RFC PATCH net-next v5 1/4] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit Sridhar Samudrala
2018-04-05 21:08 ` [RFC PATCH net-next v5 2/4] net: Introduce generic bypass module Sridhar Samudrala
2018-04-06 12:57 ` Jiri Pirko
2018-04-06 23:08 ` Samudrala, Sridhar
2018-04-05 21:08 ` [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available Sridhar Samudrala
2018-04-06 12:48 ` Jiri Pirko
2018-04-06 22:59 ` Samudrala, Sridhar
2018-04-09 8:07 ` Jiri Pirko
2018-04-09 18:47 ` Samudrala, Sridhar
2018-04-10 10:55 ` Jiri Pirko
2018-04-10 15:13 ` Samudrala, Sridhar
2018-04-10 15:22 ` Jiri Pirko
2018-04-10 15:27 ` Samudrala, Sridhar
2018-04-10 15:43 ` Jiri Pirko [this message]
2018-04-10 15:55 ` Siwei Liu
2018-04-10 15:59 ` Samudrala, Sridhar
2018-04-11 6:03 ` Jiri Pirko
2018-04-11 6:24 ` Samudrala, Sridhar
2018-04-11 8:03 ` Jiri Pirko
2018-04-11 14:45 ` Michael S. Tsirkin
2018-04-11 14:51 ` Jiri Pirko
2018-04-05 21:08 ` [RFC PATCH net-next v5 4/4] netvsc: refactor notifier/event handling code to use the bypass framework Sridhar Samudrala
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=20180410154304.GG2028@nanopsycho \
--to=jiri@resnulli.us \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=jasowang@redhat.com \
--cc=jesse.brandeburg@intel.com \
--cc=kubakici@wp.pl \
--cc=loseweigh@gmail.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sridhar.samudrala@intel.com \
--cc=stephen@networkplumber.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/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