From: "Xu, Rosen" <rosen.xu@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>, Matan Azrad <matan@mellanox.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>,
"Bie, Tiwei" <tiwei.bie@intel.com>,
"Wang, Zhihong" <zhihong.wang@intel.com>,
"Wang, Xiao W" <xiao.w.wang@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>, "Pei, Andy" <andy.pei@intel.com>,
"Roni Bar Yanai" <roniba@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers
Date: Fri, 10 Jan 2020 14:18:47 +0000 [thread overview]
Message-ID: <0E78D399C70DA940A335608C6ED296D73AC890D1@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <6026430.K2JlShyGXD@xps>
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, January 10, 2020 17:21
> To: Matan Azrad <matan@mellanox.com>; Xu, Rosen <rosen.xu@intel.com>
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>; Bie, Tiwei
> <tiwei.bie@intel.com>; Wang, Zhihong <zhihong.wang@intel.com>; Wang,
> Xiao W <xiao.w.wang@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> dev@dpdk.org; Pei, Andy <andy.pei@intel.com>; Roni Bar Yanai
> <roniba@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device
> drivers
>
> 10/01/2020 03:38, Xu, Rosen:
> > From: Matan Azrad <matan@mellanox.com>
> > > From: Xu, Rosen <rosen.xu@intel.com>
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 09/01/2020 03:27, Xu, Rosen:
> > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > 08/01/2020 13:39, Xu, Rosen:
> > > > > > > > From: Matan Azrad <matan@mellanox.com>
> > > > > > > > > From: Xu, Rosen
> > > > > > > > > > Did you think about OVS DPDK?
> > > > > > > > > > vDPA is a basic module for OVS, currently it will take
> > > > > > > > > > some exception path packet processing for OVS, so it
> > > > > > > > > > still needs to integrate
> > > > > > > eth_dev.
> > > > > > > > >
> > > > > > > > > I don't understand your question.
> > > > > > > > >
> > > > > > > > > What do you mean by "integrate eth_dev"?
> > > > > > > >
> > > > > > > > My questions is in OVS DPDK scenario vDPA device
> > > > > > > > implements eth_dev ops, so create a new class and move ifc
> > > > > > > > code to this new class
> > > > > is not ok.
> > > > > > >
> > > > > > > 1/ I don't understand the relation with OVS.
> > > > > > >
> > > > > > > 2/ no, vDPA device implements vDPA ops.
> > > > > > > If it implements ethdev ops, it is an ethdev device.
> > > > > > >
> > > > > > > Please show an example of what you claim.
> > > > > >
> > > > > > Answers of 1 and 2.
> > > > > >
> > > > > > In OVS DPDK, each network device(such as NIC, vHost etc) of
> > > > > > DPDK needs to be implemented as rte_eth_dev and provides
> > > > > > eth_dev_ops
> > > > such
> > > > > > as
> > > > > packet TX/RX for OVS.
> > > > >
> > > > > No, OVS is also using the vhost API for vhost port.
> > > >
> > > > Yes, vhost pmd is not a good example.
> > > >
> > > > > > Take vHost(Virtio back end) for example, OVS startups vHost
> > > > > > interface like
> > > > > this:
> > > > > > ovs-vsctl add-port br0 vhost-user-1 -- set Interface
> > > > > > vhost-user-1 type=dpdkvhostuser drivers/net/vhost implements
> > > > > > vHost as
> > > > rte_eth_dev
> > > > > and integrated in OVS.
> > > > > > OVS can send/receive packets to/from VM with
> > > > > > rte_eth_tx_burst()
> > > > > > rte_eth_rx_burst() which call eth_dev_ops implementation of
> > > > > drivers/net/vhost.
> > > > >
> > > > > No, it is using rte_vhost_dequeue_burst() and
> > > > > rte_vhost_enqueue_burst() which are not in ethdev.
> > > > >
> > > > > > vDPA is also Virtio back end and works like vHost, same as
> > > > > > vHost, it will be implemented as rte_eth_dev and also be integrated
> into OVS.
> > > > >
> > > > > No, vDPA is not "implemented as rte_eth_dev".
> > > >
> > > > Currently, vDPA isn't integrated with OVS.
> > > >
> > > > > > So, it's not ok to move ifc code from drivers/net.
> > > > >
> > > > > drivers/net/ifc has no ethdev implementation at all.
> > > >
> > > > For OVS hasn't integrated vDPA, it doesn't implement rte_eth_dev,
> > > > but there are many discussions in OVS community about vDPA, some
> > > > are from Mellanox, it seems vDPA port will be implemented as
> > > > rte_eth_dev port in OVS in the near feature.
> > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > patc
> > > > h
> > > >
> > >
> work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan%
> > > 4
> > > >
> > >
> 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4
> > > d
> > > >
> > > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA%
> > > 2F
> > > >
> 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0
> > > >
> > > > Matan,
> > > > Could you clarify how OVS integrates vDPA in Mellanox patch?
> > > >
> > > > >
> > > > > Rosen, I'm sorry, these arguments look irrelevant, so I won't
> > > > > consider them as blocking the integration of this patch.
> > > >
> > > > What I mentioned is not blocking the integration of this patch, I
> > > > just want to get clarification from Matan how to integrate vDPA port in
> OVS.
> > >
> > >
> > > Hi
> > >
> > > OVS like any other application should use the current API of vDPA to
> > > attach a probed vdpa device to a vhost device.
> > > See example application /examples/vdpa.
> > >
> > > Here, we just introduce a new class to hold all the vDPA drivers, no
> > > change in the API.
> > >
> > > As I understand, no vDPA device is currently integrated in OVS.
> > >
> > > I think it can be integrated only when a full offload will be
> > > integrated since the vDPA device forward the traffic from the HW
> > > directly to the virtio queue, once it will be there, I guess the
> > > offload will be configured by the representor of the vdpa device(VF)
> which is managed by an ethdev device.
> > >
> > >
> > > Matan.
> > >
> > Hi,
> >
> > I'm still confused about your last sentence " the representor of the vdpa
> device(VF) which is managed by an ethdev device".
> > My understanding is that there are some connections and dependency
> between rte_eth_dev and vdpa device?
> > Am I right or any other explanations from you?
>
> A vDPA port does not allow any ethdev operations (like rte_flow).
> In order to configure some offloads on the device, OVS needs an ethdev port.
> In Mellanox case, an ethdev VF representor port can be instantiated.
> So we may have two ports for the same device:
> - vDPA for data path with the VM
> - ethdev for offloads control path
It's obviously that OVS needs these two functions of same device.
In DPDK part, I have some concerns about how to scan, probe and bond these two ports
of same device. Could you introduce it?
As far as I know, each network device provided by DPDK is identified as a port in OVS,
do you mind to take more clarification about how to connect or bond these two
functions of same device in OVS part?
next prev parent reply other threads:[~2020-01-10 14:19 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-25 15:19 Matan Azrad
2019-12-25 15:19 ` [dpdk-dev] [PATCH v1 1/3] drivers: introduce vDPA class Matan Azrad
2020-01-07 17:32 ` Maxime Coquelin
2020-01-08 21:28 ` Thomas Monjalon
2020-01-09 8:00 ` Maxime Coquelin
2019-12-25 15:19 ` [dpdk-dev] [PATCH v1 2/3] doc: add vDPA feature table Matan Azrad
2020-01-07 17:39 ` Maxime Coquelin
2020-01-08 5:28 ` Tiwei Bie
2020-01-08 7:20 ` Andrew Rybchenko
2020-01-08 10:42 ` Matan Azrad
2020-01-08 13:11 ` Andrew Rybchenko
2020-01-08 17:01 ` Matan Azrad
2020-01-09 2:15 ` Tiwei Bie
2020-01-09 8:08 ` Matan Azrad
2019-12-25 15:19 ` [dpdk-dev] [PATCH v1 3/3] drivers: move ifc driver to the vDPA class Matan Azrad
2020-01-07 18:17 ` Maxime Coquelin
2020-01-07 7:57 ` [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers Matan Azrad
2020-01-08 5:44 ` Xu, Rosen
2020-01-08 10:45 ` Matan Azrad
2020-01-08 12:39 ` Xu, Rosen
2020-01-08 12:58 ` Thomas Monjalon
2020-01-09 2:27 ` Xu, Rosen
2020-01-09 8:41 ` Thomas Monjalon
2020-01-09 9:23 ` Maxime Coquelin
2020-01-09 9:49 ` Xu, Rosen
2020-01-09 10:42 ` Maxime Coquelin
2020-01-10 2:40 ` Xu, Rosen
2020-01-09 10:42 ` Maxime Coquelin
2020-01-09 10:53 ` Xu, Rosen
2020-01-09 11:34 ` Matan Azrad
2020-01-10 2:38 ` Xu, Rosen
2020-01-10 9:21 ` Thomas Monjalon
2020-01-10 14:18 ` Xu, Rosen [this message]
2020-01-10 16:27 ` Thomas Monjalon
2020-01-09 11:00 ` [dpdk-dev] [PATCH v2 " Matan Azrad
2020-01-09 11:00 ` [dpdk-dev] [PATCH v2 1/3] drivers: introduce vDPA class Matan Azrad
2020-01-09 11:00 ` [dpdk-dev] [PATCH v2 2/3] doc: add vDPA feature table Matan Azrad
2020-01-10 18:26 ` Thomas Monjalon
2020-01-13 22:40 ` Thomas Monjalon
2020-01-09 11:00 ` [dpdk-dev] [PATCH v2 3/3] drivers: move ifc driver to the vDPA class Matan Azrad
2020-01-09 17:25 ` Matan Azrad
2020-01-10 1:55 ` Wang, Haiyue
2020-01-10 9:07 ` Matan Azrad
2020-01-10 9:13 ` Thomas Monjalon
2020-01-10 12:31 ` Wang, Haiyue
2020-01-10 12:34 ` Maxime Coquelin
2020-01-10 12:59 ` Thomas Monjalon
2020-01-10 19:17 ` Kevin Traynor
2020-01-13 22:57 ` Thomas Monjalon
2020-01-13 23:08 ` [dpdk-dev] [PATCH v2 0/3] Introduce new class for vDPA device drivers Thomas Monjalon
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=0E78D399C70DA940A335608C6ED296D73AC890D1@SHSMSX104.ccr.corp.intel.com \
--to=rosen.xu@intel.com \
--cc=andy.pei@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=matan@mellanox.com \
--cc=maxime.coquelin@redhat.com \
--cc=roniba@mellanox.com \
--cc=thomas@monjalon.net \
--cc=tiwei.bie@intel.com \
--cc=xiao.w.wang@intel.com \
--cc=zhihong.wang@intel.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 NNTP newsgroup(s).