DPDK patches and discussions
 help / color / mirror / Atom feed
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&amp;data=02%7C01%7Cmatan%
> > > 4
> > > >
> > >
> 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4
> > > d
> > > >
> > > 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&amp;sdata=TA%
> > > 2F
> > > >
> 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&amp;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?


  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).