Re: [ovs-dev] [dpdk-users] adding dpdk ports sharing same pci address to ovs-dpdk bridge
20/09/2017 19:33, Kevin Traynor: > On 09/08/2017 10:56 AM, Loftus, Ciara wrote: > >> Hi, > >> > >> I have compiled and built ovs-dpdk using DPDK v17.08 and OVS v2.8.0. The > >> NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual port 10G > >> NIC. The problem with this NIC is that it provides only one PCI address for > >> both the 10G ports. > >> > >> So when I am trying to add the two DPDK ports to my br0 bridge > >> > >> # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk > >> options:dpdk-devargs=0002:01:00.0 > >> > >> # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk > >> options:dpdk-devargs=0002:01:00.0 > >> > >> The port dpdk1 is added successfully and able to transfer data, but adding > >> dpdk0 to br0 fails: [...] > >> With OVS v2.6.1 I never had this problem as dpdk-devargs was not > >> mandatory > >> and just specifying port name was enough to add that port to bridge. > >> > >> Is there a way to add port both ports to bridge ? > > > > It seems the DPDK function rte_eth_dev_get_port_by_name() will always > > return the port ID of the first port on your NIC, when you specify the > > single PCI address and that's where the problem is. There doesn't seem to > > be a way currently to indicate to the calling application that in fact two > > (or more) port IDs are associated with the one PCI address. We have two ports (with the same PCI address) so we should have two different names. Where the names passed to rte_eth_dev_get_port_by_name() come from? It is the user parameter from options:dpdk-devargs=0002:01:00.0, right? > > I am cc-ing DPDK users mailing list for hopefully some input. Are there any > > plans for the rte_eth_dev_get_port_by_name function to be compatible with > > NICs with multiple ports under the same PCI address? We cannot return two different ports for the same name. There are two issues here: - the input should not be the PCI address - the ethdev function should look at ethdev name, not rte_device one The idea is that we have only one rte_device object and we instantiate two rte_eth_dev ports. An ethdev port can be identified with its id (a number) or its unique name. Unfortunately, the user cannot guess the port id or the name set by the PMD. > Hi Adrien/Nelio, > > Is this something you can answer? We're wondering how to handle this in > OVS and whether a temporary or long term solution is needed. I suggest to rely on ethdev name. You will need to show to the user the mapping between the bus information (PCI id here) and the device names. Another alternative is to add a new function returning all ethdev ports associated to a given rte_device resource. So you would get two ports and you could pick one on the first "add-port", and the other one for the second "add-port" command. It means the user would be forced to add them in the right order if he wants a reproducible result. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [dpdk-users] adding dpdk ports sharing same pci address to ovs-dpdk bridge
21/09/2017 10:04, Loftus, Ciara: > > 20/09/2017 19:33, Kevin Traynor: > > > On 09/08/2017 10:56 AM, Loftus, Ciara wrote: > > > > It seems the DPDK function rte_eth_dev_get_port_by_name() will > > > > always return the port ID of the first port on your NIC, > > > > when you specify the single PCI address and that's where the > > > > problem is. There doesn't seem to be a way currently to > > > > indicate to the calling application that in fact two > > > > (or more) port IDs are associated with the one PCI address. > > > > We have two ports (with the same PCI address) so we should have > > two different names. > > Where the names passed to rte_eth_dev_get_port_by_name() come from? > > It is the user parameter from options:dpdk-devargs=0002:01:00.0, right? > > Yes, we're using the PCI address specified by the user in dpdk-devargs. > > > > > I am cc-ing DPDK users mailing list for hopefully some input. > > > > Are there any plans for the rte_eth_dev_get_port_by_name function > > > > to be compatible with NICs with multiple ports under the same PCI > > > > address? > > > > We cannot return two different ports for the same name. > > There are two issues here: > > - the input should not be the PCI address > > - the ethdev function should look at ethdev name, not rte_device > > one > > This would require the user having to "guess" the DPDK ethdev name > which is something we'd like to avoid. Yes, but you can provide a way to list the ports with their names and characteristics. > We had the same problem using DPDK port IDs and decided not to use > them anymore, and use the PCI instead as it took the guesswork out. > Ethdev names and port IDs can change between tests, unlike the PCI > address which tends to remain constant for a device. We can add a requirement on ethdev names and make sure they remain constant for a given port. > > The idea is that we have only one rte_device object and we instantiate > > two rte_eth_dev ports. > > An ethdev port can be identified with its id (a number) or its unique name. > > Unfortunately, the user cannot guess the port id or the name set by the > > PMD. > > Exactly. Thanks for clarifying what's going on under the hood. > > Ciara > > > > > > Hi Adrien/Nelio, > > > > > > Is this something you can answer? We're wondering how to handle this in > > > OVS and whether a temporary or long term solution is needed. > > > > I suggest to rely on ethdev name. > > You will need to show to the user the mapping between the bus information > > (PCI id here) and the device names. > > > > Another alternative is to add a new function returning all ethdev ports > > associated to a given rte_device resource. > > So you would get two ports and you could pick one on the first "add-port", > > and the other one for the second "add-port" command. > > It means the user would be forced to add them in the right order if he > > wants a reproducible result. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [dpdk-dev] tunnel endpoint hw acceleration enablement
Hi Declan, 27/02/2018 16:55, Doherty, Declan: > Invite for a DPDK community call to discuss the tunnel endpoint hw > acceleration proposal in this RFC > (http://dpdk.org/ml/archives/dev/2017-December/084676.html) and the related > community feedback. The email does not show the date and time of your invitation. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Direct using of 'rte_eth_devices' in DPDK apps.
Hi, 16/11/2018 09:42, Ilya Maximets: > Hi, > While discussing the ways to enable DPDK 18.11 new features in OVS > there was suggestions to use 'rte_eth_devices[]' array directly. > But this array is marked as '@internal' and also it located in > the internal header 'lib/librte_ethdev/rte_ethdev_core.h' with the > following disclaimer: > > /** > * @file > * > * RTE Ethernet Device internal header. > * > * This header contains internal data types. But they are still part of the > * public API because they are used by inline functions in the published API. > * > * Applications should not use these directly. > * > */ > > From the other hand, test-pmd and some example apps in DPDK source > tree are using this array for various reasons. > > So, is it OK to use this array directly or not? Good question :) Thanks for bringing this discussion. As you said, it is public because of inline functions using it directly for performance purpose. The DPDK API is bad for separating public and internal stuff. And over time, there is not a lot of attention on trying to not use internal symbols in applications. > In general we need to change the API, i.e. make 'rte_eth_devices' part > of a public API. Or change the test-pmd and example apps to stop > using it. I agree we need to decide an option and make it clear. We can try to make this variable private and add more public functions to use it (I'm thinking at more iterators like sibling ones). It would clarify the API. It can be evaluated what is the real cost after compiler optimization for Rx/Tx functions. It can also be evaluated to uninline functions. On the other hand, we can wonder what is the real benefit of trying to hide access to internal resources. Should we make all public? > One more related question: Is it OK to access internal device > stuff using 'device' pointer obtained by 'rte_eth_dev_info'? > This looks really dangerous. It's unclear why pointers like this > exposed to user. It's a lot easier to expose pointers than doing a good API for all uses. We need to question what is really dangerous and what we want to avoid? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5] netdev-dpdk: support port representors
16/01/2019 12:38, Kevin Traynor: > On 01/16/2019 11:06 AM, Thomas Monjalon wrote: > > 16/01/2019 11:56, Kevin Traynor: > >> On 01/16/2019 10:21 AM, Thomas Monjalon wrote: > >>> But honestly, I doubt you need to talk about representors in this patch. > >>> The change is to support multi-ports device generally. > >> > >> ok, then just need a way to tell OVS user that the new functionality is > >> existing. > > > > Which functionality? closing a port without closing others? > > It looks like a bug fix to me :) > > A bug? NEVER :-) I just mean the code is enabling some new > functionality for a user, so they should know that it's available now. Yes it was a bug: if you close a Chelsio port, it was closing both ports. Except that, what is the functionality from your point of view? You think we need to state that multi-ports devices are supported? Isn't it a statement for release notes? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5] netdev-dpdk: support port representors
16/01/2019 11:03, Ophir Munk: > Hi Kevin and thank you for your comments. > Please see inline... > > From: Kevin Traynor > > On 01/15/2019 09:47 AM, Ophir Munk wrote: > > > Dpdk port representors were introduced in dpdk versions 18.xx. > > > Prior to port representors there was a one-to-one relationship between > > > an rte device (e.g. PCI bus) and an eth device (referenced as dpdk > > > port id in OVS). With port representors the relationship becomes > > > one-to-many rte device to eth devices. > > > For example in [3] there are two devices (representors) using the same > > > PCI physical address :08:00.0: ":08:00.0,representor=[3]" and > > > ":08:00.0,representor=[5]". > > > This commit handles the new one-to-many relationship. For example, > > > when one of the device port representors in [3] is closed - the PCI > > > bus cannot be detached until the other device port representor is > > > closed as well. OVS remains backward compatible by supporting dpdk > > > legacy PCI ports which do not include port representors. > > > Dpdk port representors related commits are listed in [1]. Dpdk port > > > representors documentation appears in [2]. A sample configuration > > > which uses two representors ports (the output of "ovs-vsctl show" > > > command) is shown in [3]. > > > > > > > Hi Ophir, I had a scan through and there isn't any documentation/examples > > for this outside the commit message. I think a user would need something > > basic, or at least reference to know that this exists and how to use it. The user needs to know the DPDK syntax to reference DPDK ports. This documentation should be provided by DPDK. We don't have a doc summarizing all at the moment (I will work on it). I suggest you collect URLs for pieces of docs and list them in OVS doc about dpdk-devargs. > > > [2] > > > doc/guides/prog_guide/switch_representation.rst > > > > > I now realize that the reference given in [2] requires downloading DPDK. > In v6 I will update it with a new reference: > > https://doc.dpdk.org/guides-18.08/prog_guide/switch_representation.html No need to specify a version: https://doc.dpdk.org/guides/prog_guide/switch_representation.html > which includes abundant of documentation/examples. > Can you please have a look and let me know if it is sufficient, or maybe you > have other ideas where more documentation should be added. There is also some documentation for representor syntax: https://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html#ethernet-device-standard-device-arguments But honestly, I doubt you need to talk about representors in this patch. The change is to support multi-ports device generally. The representor ports are just a use case of multi-ports. Other use cases: https://doc.dpdk.org/guides/nics/mlx4.html#implementation-details https://doc.dpdk.org/guides/nics/cxgbe.html#limitations For these use cases, we can use the mac= argument in devargs. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovs-dev, dpdk-hwol, v1] netdev-dpdk: support port representors
16/12/2018 13:02, Ophir Munk: > Hi Ilya, > Please find comments inline. > > From: Ilya Maximets > > > > Not a full review. Just one comment inline. > > > > Best regards, Ilya Maximets. > > > > On 12.12.2018 2:34, Ophir Munk wrote: > > > Dpdk port representors were introduced in dpdk 18.xx. > > > . > > > > > > -rte_eth_dev_close(port_id); > > > +rte_dev = rte_eth_devices[port_id].device; > > > > > > We should not use 'rte_eth_devices' directly because it's internal to DPDK. > > See the discussion here: > > http://mails.dpdk.org/archives/dev/2018-November/119198.html > > The discussions mentioned in the link raised pros and cons for using a direct > access to rte_eth_devices[] but was not conclusive. > I am in favor of keeping the direct access to rte_eth_devices array for the > following reasons: > 1. Using rte_eth_dev_info_get() API uses the same pointer to the internal > rte_eth_devices[] array. So actually it is as dangerous as accessing the > array directly. > 2. Theoretically there is logic in using the API as it may have a safer > implementation in the future. However, I talked with Thomans Monjalon - the > maintainer of this API - and he recommended using the direct array access. > Thomas mentioned that this API will be dropped. > > Thomas - can you please share your view on this topic? I agree with the idea of avoiding direct access to this structure. That's why I wrote a new function specifically for this use case: https://patches.dpdk.org/patch/48429/ About workarounding the direct access with rte_eth_dev_info_get(), I am not sure it is a great idea. In my opinion, it is best to keep the direct access to the array and add a comment about the need to replace it with a proper API. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4] netdev-dpdk: support port representors
Hi,
10/01/2019 12:32, Ilya Maximets:
> On 08.01.2019 12:31, Ophir Munk wrote:
> > if (dev->attached) {
> > +/* Remove the port eth device. */
> > rte_eth_dev_close(dev->port_id);
> > -rte_eth_dev_info_get(dev->port_id, _info);
> > -if (dev_info.device && !rte_dev_remove(dev_info.device)) {
> > -VLOG_INFO("Device '%s' has been detached", dev->devargs);
>
> Please keep this log message for the successful case.
>
> > -} else {
> > -VLOG_ERR("Device '%s' can not be detached", dev->devargs);
> > +VLOG_INFO("Device '%s' has been removed", dev->devargs);
> > +/* If this is the last port_id using this rte device
> > + * remove this rte device and all its eth devices.
> > + * FIXME: avoid direct access to DPDK internal array
> > rte_eth_devices.
> > + */
> > +rte_dev = rte_eth_devices[dev->port_id].device;
> > +if (netdev_dpdk_get_num_ports(rte_dev) == 1) {
>
> rte_eth_dev_close() sets the RTE_ETH_DEV_UNUSED state for PMDs with
> RTE_ETH_DEV_CLOSE_REMOVE flag.
> The function netdev_dpdk_get_num_ports() skips unused ports.
> The result should not be equal to 1. We need the other way to detect
> the siblings or close the port after calculating them.
> In this case we'll probably do not need to have check for UNUSED state
> inside the _get_num_ports().
Maybe I don't understand correctly.
Why do you want to count closed sibling ports?
> > +if (rte_dev_remove(rte_dev) < 0) {
> > +VLOG_ERR("Device '%s' can not be detached", dev->devargs);
> > +}
> > }
> > }
[...]
> Also, do we still need netdev_dpdk_get_port_by_mac() if we're using
> devargs iterator ?
The devargs iterator manages "mac=" property in DPDK 18.11.
[...]
> > -rte_eth_dev_close(port_id);
> > +/* FIXME: avoid direct access to DPDK internal array rte_eth_devices.
> > */
> > +rte_dev = rte_eth_devices[port_id].device;
> > +if (netdev_dpdk_get_num_ports(rte_dev)) {
>
> Probably same here.
> DPDK does not set RTE_ETH_DEV_UNUSED state for PMDs without
> RTE_ETH_DEV_CLOSE_REMOVE flag.
If RTE_ETH_DEV_CLOSE_REMOVE is not set, you should call rte_dev_remove()
just after rte_eth_dev_close().
> > +response = xasprintf("Device '%s' is being shared with other "
> > + "interfaces. Remove them before detaching.",
> > + argv[1]);
> > +goto error;
> > +}
> >
> > -rte_eth_dev_info_get(port_id, _info);
> > -if (!dev_info.device || rte_dev_remove(dev_info.device)) {
> > -response = xasprintf("Device '%s' can not be detached", argv[1]);
> > +rte_eth_dev_close(port_id);
> > +if (rte_dev_remove(rte_dev) < 0) {
> > +response = xasprintf("Device '%s' can not be removed", argv[1]);
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4] netdev-dpdk: support port representors
10/01/2019 15:23, Ilya Maximets:
> On 10.01.2019 16:42, Thomas Monjalon wrote:
> > Hi,
> >
> > 10/01/2019 12:32, Ilya Maximets:
> >> On 08.01.2019 12:31, Ophir Munk wrote:
> >>> if (dev->attached) {
> >>> +/* Remove the port eth device. */
> >>> rte_eth_dev_close(dev->port_id);
> >>> -rte_eth_dev_info_get(dev->port_id, _info);
> >>> -if (dev_info.device && !rte_dev_remove(dev_info.device)) {
> >>> -VLOG_INFO("Device '%s' has been detached", dev->devargs);
> >>
> >> Please keep this log message for the successful case.
> >>
> >>> -} else {
> >>> -VLOG_ERR("Device '%s' can not be detached", dev->devargs);
> >>> +VLOG_INFO("Device '%s' has been removed", dev->devargs);
> >>> +/* If this is the last port_id using this rte device
> >>> + * remove this rte device and all its eth devices.
> >>> + * FIXME: avoid direct access to DPDK internal array
> >>> rte_eth_devices.
> >>> + */
> >>> +rte_dev = rte_eth_devices[dev->port_id].device;
> >>> +if (netdev_dpdk_get_num_ports(rte_dev) == 1) {
> >>
> >> rte_eth_dev_close() sets the RTE_ETH_DEV_UNUSED state for PMDs with
> >> RTE_ETH_DEV_CLOSE_REMOVE flag.
> >> The function netdev_dpdk_get_num_ports() skips unused ports.
> >> The result should not be equal to 1. We need the other way to detect
> >> the siblings or close the port after calculating them.
> >> In this case we'll probably do not need to have check for UNUSED state
> >> inside the _get_num_ports().
> >
> > Maybe I don't understand correctly.
> > Why do you want to count closed sibling ports?
>
> Proposed version of 'netdev_dpdk_get_num_ports' iterates over
> 'dpdk_list' which contains only ports that currently opened by OVS.
> So, the only port that could have UNUSED state in that list is the
> port that we're just closed here. If we'll count number of siblings
> before closing the port where should be no UNUSED ports in that list.
>
> The issue I tried to raise here is that rte_eth_dev_close() changed the
> state only for PMDs with RTE_ETH_DEV_CLOSE_REMOVE. So, the result
> of 'netdev_dpdk_get_num_ports' will be different for different PMDs.
Yes, that's true.
You can manage it two ways:
- you rely on OVS list of open ports
- you remove the device completely (as before)
for PMDs not supporting RTE_ETH_DEV_CLOSE_REMOVE
> >>> +if (rte_dev_remove(rte_dev) < 0) {
> >>> +VLOG_ERR("Device '%s' can not be detached",
> >>> dev->devargs);
> >>> +}
> >>> }
> >>> }
> >
> > [...]
> >> Also, do we still need netdev_dpdk_get_port_by_mac() if we're using
> >> devargs iterator ?
> >
> > The devargs iterator manages "mac=" property in DPDK 18.11.
>
> Good.
>
> >
> > [...]
> >>> -rte_eth_dev_close(port_id);
> >>> +/* FIXME: avoid direct access to DPDK internal array
> >>> rte_eth_devices. */
> >>> +rte_dev = rte_eth_devices[port_id].device;
> >>> +if (netdev_dpdk_get_num_ports(rte_dev)) {
> >>
> >> Probably same here.
> >> DPDK does not set RTE_ETH_DEV_UNUSED state for PMDs without
> >> RTE_ETH_DEV_CLOSE_REMOVE flag.
> >
> > If RTE_ETH_DEV_CLOSE_REMOVE is not set, you should call rte_dev_remove()
> > just after rte_eth_dev_close().
>
> And what if we call rte_dev_remove() after rte_eth_dev_close() for
> PMD with RTE_ETH_DEV_CLOSE_REMOVE ?
Then you release the full device, as before with the old "detach" API.
It makes no difference for single-port device.
But it is bad for multi-port devices (which should already implement
RTE_ETH_DEV_CLOSE_REMOVE).
> >>> +response = xasprintf("Device '%s' is being shared with other "
> >>> + "interfaces. Remove them before detaching.",
> >>> + argv[1]);
> >>> +goto error;
> >>> +}
> >>>
> >>> -rte_eth_dev_info_get(port_id, _info);
> >>> -if (!dev_info.device || rte_dev_remove(dev_info.device)) {
> >>> -response = xasprintf("Device '%s' can not be detached", argv[1]);
> >>> +rte_eth_dev_close(port_id);
> >>> +if (rte_dev_remove(rte_dev) < 0) {
> >>> +response = xasprintf("Device '%s' can not be removed", argv[1]);
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] OVS robot discussion - check API integration
13/02/2019 17:56, Aaron Conole: > Ilya Maximets writes: > > And we, actually, already have special ovs-build mail-list. It could > > be used if you'll decide to choose DPDK way of working with patchwork. > > It looks intriguing. I like the idea that anyone could then contribute > 'check results' to the patchwork project. But, it seems like it would > require some additional infrastructure. We would need a script that > will periodically run against the list, or possibly an alias that is > subscribed to the list that is just an alias to > /bin/process_ovs_build_mails.sh that can update the check interface. The best is to have a hook in the mail archiving system, so you can reference the report in the mail archives as soon as it is published. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] OVS robot discussion - check API integration
11/02/2019 18:03, Ben Pfaff: > On Mon, Feb 11, 2019 at 10:24:01AM -0500, Aaron Conole wrote: > > I'm following up on a discussion where we briefly talked about adding > > a 'check' to OVS patch series during the OVS Conference. 'Check' is > > what the patchwork project provides to show that certain tests have been > > performed. It is made up of a name, a status, and a URL. Some of the > > projects in the ozlabs patchwork instance are using the check feature > > already, so there's some examples to reference. > > > > My idea is to push some data into travis / cirrus that can be used to > > insert a check against a patch series. This would allow committers to > > look at the status page on patchwork and see at a glance the links to > > the travis, and if a robot email was sent. > > The approach seems reasonable. > > You mention that there are existing examples. How do they do it? In DPDK project, we are sending the results to a specific mailing-list with this script: http://git.dpdk.org/tools/dpdk-ci/tree/tools/send-patch-report.sh It is possible to filter some reports by using mail filtering. Then it is parsed on the server by the following script which updates patchwork data using server-specific credentials: http://git.dpdk.org/tools/dpdk-ci/tree/tools/update-pw.sh Note that we improved patchwork to highlight CI results with colors: https://patches.dpdk.org ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS dpdk-latest branch & UNH testing
29/04/2019 10:49, Ilya Maximets: > On 25.04.2019 13:21, Ian Stokes wrote: > > Hi All, > > > > At last weeks OVS community call [1] the topic of the UNH DPDK lab testing > > OVS was raised, specifically the issue of the target branches being used so > > I wanted to kick off a wider discussion on the ML. > > > > Currently the UNH Lab tests target the DPDK master branch and the > > dpdk-latest branch in the OVS repo. > > > > To date, we've maintained the dpdk-latest branch by merging OVS master > > every few weeks and applying any required patches to ensure compilation & > > existing feature functionality with DPDK master branch at that time. > > > > A concern from UNH is that this introduces 2 moving targets i.e. breakages > > could be introduced either by commits on DPDK master or a commit merged > > from OVS master into dpdk-latest. > > > > From a UNH perspective, it was suggested that it would be easier if the > > dpdk-latest branch did not have regular merges from OVS master. Only > > patches that enable DPDK master compilation and functionality would be > > committed to dpdk-latest. > > > > This does reduce the scope of introducing breakage as now breakage should > > only occur due to a change in DPDK master. > > > > However the advantage of keeping dpdk-latest in sync with both DPDK master > > and OVS master is that there is better visibility WRT to changes required > > in OVS master when it eventually transitions to the latest DPDK LTS > > release. IMO, this process has worked well for the OVS community since > > being introduced. > > > > I would prefer to keep the current process for dpdk-latest, my thinking > > here is that before pushing the latest merge of OVS master to dpdk-latest > > it should undergo validation testing anyhow (travis, unit tests, basic p2p > > & pvp). If these are passing before the changes are pushed then I would > > think it there would be minimal danger at least WRT OVS code base changes > > breaking the UNH tests. > > > > Another proposal suggested was that another branch could be introduced in > > the OVS repo specifically to enable UNH OVS DPDK testing. I'm not a fan of > > this however, I think it's adding overhead to avoid an issue (OVS master > > merge causing dpdk-latest breakage) that should be addressed regardless if > > it occurs. > > > > What are peoples thoughts? > > Hi. > > I'd also prefer "current" model but with a few changes. I'm suggesting > a periodic 'git pull --rebase' from master to dpdk-latest instead of merge. > 'dpdk-latest' branch is not a stable branch and I don't think that anyone > should use it on a regular basis. So it should be expected that this branch > could be rebased at any time. This should not produce any issues for CI > systems as they are commonly clones entire repo or checkouts branch to the > new local branch. This way DPDK lab will test dpdk commits over the current > 'dpdk-latest' branch of OVS which will be periodically moved to match with > latest OVS master. Of course, the branch should be validated by Travis or > local build before the force-push to avoid DPDK Lab test failures caused by > OVS. We need to update the travis scripts on this branch to build with > DPDK master. > > Rebasing produces exactly same number of conflicts as merging, however it > keeps the history clean and readable. Current merge strategy only > complicates the history making it impossible to say what commits are differ. > And also in addition to resolving merge conflicts we'll have to resolve same > conflicts again while pulling changes back to master while moving to next > DPDK LTS. > > --- > > I have one important question: What we're trying to test? > 1. Does it check that OVS builds with new DPDK? Yes > 2. Or it tests the OVS performance with new DPDK? It would be more about DPDK perf tested with OVS. > 3. Or it tests DPDK patches that they doesn't break the API currently used by > OVS? Yes > 4. Or it tests the performance of new OVS patches? No, the DPDK lab is more interested in DPDK behaviour and perf. > The target of 1 could be achieved by the Travis build in OVS repo. > The target of 2 does not have much in common with OVS. Achieved by simple DPDK > performance tests already existed on lab.dpdk.org. Perf variations may be different in the OVS scenario. > The target of 3 makes no much sense because we need to fix OVS, not the DPDK. It allows to check that the behaviour (part of API) is not broken. > Covered by the target of question 1. > The target of 4 is probably the most interesting, however it's not the case > of building with latest DPDK master. This should be done by testing current > OVS master with stable DPDK. Yes I agree. > So, what is the goal of this testing? I'm asking because there is no any > information available here of on lab.dpdk.org. We agreed to use OVS as an interesting use case of DPDK. The main purpose is to test DPDK, so the moving target should be DPDK. However,
Re: [ovs-dev] [ovs-dev, v1] netdev-rte-offloads: Reassign vport netdev functions.
21/04/2019 11:11, Ophir Munk: > Thomas - would you like to explain more on the origins of "rte"? Ian explained (below) the origin quite clearly. It has been decided in the early days by Intel. > From: Ian Stokes > > On 4/17/2019 5:34 PM, Ben Pfaff wrote: > > > On Wed, Apr 17, 2019 at 11:45:33AM -0400, Aaron Conole wrote: > > >> rte comes from dpdk as an acronym for Run Time Environment. Maybe > > >> even just dropping the 'rte_' portion? > > > > > > *That* is what rte stands for? What a ridiculously generic name. > > > It's like naming a library Operating System. Yes I agree that it's ridiculous :) I already proposed to replace rte_ with dpdk_ prefix but the vast majority was against a big replacement. Would you support such a change? > > This piqued my interest also, with DPDK in the early days it was targeting > > bare > > metal comms systems, so the original API was LWRTE (LiteWeight Run Time > > Environment) which became RTE as it moved on from bare metal, so it seems > > more of a legacy convention. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Remove libmnl for MLX5 PMD
On Tue, Jun 23, 2020 at 6:49 PM Timothy Redaelli wrote: > > libmnl is not used anymore for MLX5 PMD since DPDK 19.08. Why don't you use pkg-config? All these kind of dependencies are managed through libdpdk.pc which is generated with meson. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Remove libmnl for MLX5 PMD
25/06/2020 13:28, Timothy Redaelli: > On Thu, 25 Jun 2020 09:32:23 +0200 > Thomas Monjalon wrote: > > > On Tue, Jun 23, 2020 at 6:49 PM Timothy Redaelli > > wrote: > > > > > > libmnl is not used anymore for MLX5 PMD since DPDK 19.08. > > > > Why don't you use pkg-config? > > All these kind of dependencies are managed through libdpdk.pc > > which is generated with meson. > > Because on Fedora/RHEL we don't use meson (yet) since it's not possible > to choose the list of PMDs to build and testpmd links to some of the > PMDs we don't ship Wrong: there is the option disable_drivers accepting a list. Anyway, makefiles won't be part of DPDK 20.11. You must switch to meson for DPDK compilation. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] RFC: netdev-dpdk: Add Windows support.
06/10/2021 19:00, William Tu: > The patch adds OVS-DPDK supports on Windows. [...] > Implementation on Windows > - > It's harder than I thought due to my Linux only background. > Sergey and I first need to add meson build support to OVS, in order > to make compiling and linking to Windows DPDK library easier[2]. > In this patch, we use clang compiler on Windows to compile DPDK and > OVS, and OVS links to DPDK static library (Dynamic lib still not > supported yet in DPDK Windows). > > Windows DPDK library hasn't finished all its library/driver porting > to Windows. So a couple of DPDK library code used by OVS doesn't > compile. For examples: > 1) ovs-numa.c: used to detect lcores used by DPDK. > 2) open_memstream, fopencookies: used to redirect DPDK logs. > 3) vhostuser doesn't support: used to connect VM/container. > 4) dpdk-socket-mem not support: configuration > I simply remove them in this patch. > In the future, I will probably refactor or #ifdef. Yes please, removing code is clearly not the right direction :) [...] > Future Work > --- > In priority ordering > a. Add CI or Dockerfile for building the code > b. Performance numbers, compared with OVS kernel datapath > c. Try rte_flow HW offload on Windows > d. Resolve all the compiler warnings > e. Refactor the vhostuser code > > Some thoughts: > f. With clang support on Windows, can we remove MSVC? >so OVS will have less compiler-specific code, ex: >include\openvswitch\compiler.h > g. DPDK starts to implement pthread in Windows, can >OVS uses pthread library from DPDK, instead of pthreads4w? The thread API is not ready yet in DPDK. What would be the benefit for OVS to use the same pthread layer as DPDK? OVS needs to be able to compile without DPDK. > h. Mingw/msys is pretty slow, by switching to meson+clang, >what's the improvement of build process? > f. How does OVS-DPDK connect to VM/Container in Windows? >There is no vhostuser, we should look at netvsc/vmbus. > > I got lots of help from many people in DPDK community, thanks! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS DPDK DSA Architecture/Design Discussion
15/03/2022 12:14, Stokes, Ian: > > 15/03/2022 11:27, Stokes, Ian: > > > Hi All, > > > > > > We'd like to put a public meeting in place for the stakeholders > > > of DPDK and OVS to discuss the next steps and design of > > > the DSA library along with its integration in OVS. > > > > There is no DSA library. > > Do you mean the IOAT driver in DPDK for the DMA library? > > Apologies Thomas, > > DMA-Dev library is actually what's intended to be discussed to clarify. > Will re-send the invite with the correct title. If you want to have a good number of attendees, you should postpone to a later date, so we can plan in advance. You also need to describe the problem to discuss. That's really better to start with emails, and to have a summary after the meeting. > > If it is just for discussing the Intel driver, no way I attend. > > And even if it is for discussing the DMA library integration, > > I don't understand why the DPDK community is required. > > > > If there is an issue with the library API, please tell it. > > We need email discussions, not meeting request sent few hours in advance. > > Ian, I know you are not a beginner in the community, what happens? So if I understand well, there is no urgent problem to discuss? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS DPDK DSA Architecture/Design Discussion
15/03/2022 11:27, Stokes, Ian: > Hi All, > > We'd like to put a public meeting in place for the stakeholders > of DPDK and OVS to discuss the next steps and design of > the DSA library along with its integration in OVS. There is no DSA library. Do you mean the IOAT driver in DPDK for the DMA library? If it is just for discussing the Intel driver, no way I attend. And even if it is for discussing the DMA library integration, I don't understand why the DPDK community is required. If there is an issue with the library API, please tell it. We need email discussions, not meeting request sent few hours in advance. Ian, I know you are not a beginner in the community, what happens? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC PATCH v2] dpdk: Update to use v22.11.
30/11/2022 16:30, Stokes, Ian:
> > Hi Ian,
> >
> > Cc: Thomas and John
> >
> > On Wed, Nov 23, 2022 at 12:52 PM Ian Stokes wrote:
> > > diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> > > index 23c8bbb7a..0aa90e55e 100755
> > > --- a/.ci/linux-build.sh
> > > +++ b/.ci/linux-build.sh
> > > @@ -142,7 +142,7 @@ function install_dpdk()
> > > fi
> > > # No cache or version mismatch.
> > > rm -rf dpdk-dir
> > > -wget https://fast.dpdk.org/rel/dpdk-$1.tar.xz
> > > +wget https://git.dpdk.org/dpdk/snapshot/dpdk-$1.tar.xz
> > > tar xvf dpdk-$1.tar.xz > /dev/null
> > > DIR_NAME=$(tar -tf dpdk-$1.tar.xz | head -1 | cut -f1 -d"/")
> > > mv ${DIR_NAME} dpdk-dir
> >
> > dpdk.org server experienced a quite heavy load this morning, with many
> > clients requesting git related operations through http.
> > I am not sure what or who triggered this, but I just remembered this patch
> > here.
> >
> > Downloading a rc4 tarball through dpdk.org cgit is to be avoided.
> > dpdk.org server does not cache this kind of operations, it is heavy on
> > cpu, memory and bandwidth.
> >
> >
> > I think OVS should switch to the github mirror, this would work for
> > both rc and final release tarballs.
> > IOW: wget https://github.com/DPDK/dpdk/archive/refs/tags/v$1.tar.gz
> >
> > One drawback is that github does not seem to provide xz compressed
> > tarballs, so you would need to update the script further.
> >
>
> Thanks for the input David, I've posted a v3 but didn’t include this change
> as I wanted to discuss a bit further.
>
> So we use DPDK.org in our ci but we also make reference to its use throughout
> the OVS documentation when users wish to download DPDK, should this also be
> replaced with github?
>
> I guess to my mind if github is the preferred method to retrieve the repo
> then does it raise the question of dpdk org in general providing the
> releases? Is there a plan to transition completely to github for DPDK in the
> future?
>
> If the preferred method is to go ahead with github then thats OK on my side
> but I think it would be better to keep that change in a separate patch along
> with an explanation as to why github should be used rather than dpdk.org as
> we've been using the current approach for a few years without issue.
fast.dpdk.org is fine and preferred.
git.dpdk.org should not be used for tarball download in general.
github.com/DPDK is OK for tarball download, including release candidates.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
