[dpdk-dev] DPDK Community Conference Call - Friday 31st October
On Fri, Oct 31, 2014 at 05:36:59PM +, O'driscoll, Tim wrote: > Thanks again to those who attended the call earlier. Hopefully people found > it useful. > > We'll schedule a follow-up call for 2 weeks' time. One thing that we do want > to look into is an easy way to allow screen sharing, so that we can use some > slides to guide the discussion. Internally within Intel we use MS Lync. We > can try that, but it's not always very user-friendly for external > participants, and doesn't have a Linux client. Other options would include > GoToMeeting or WebEx. If anybody has input on a good tool for this, let me > know. > Don't use Lync, its a horrid tool. As you note, there is no linux client (nor a mac client that I'm aware of). Google hangouts offers screen sharing, and is free for anyone to use. > We covered the following features from our 2.0 list today, and will discuss > the remainder on the next call. I've called out below who on our side was > describing each of the features, and included their email addresses. If > anybody has further questions on these, feel free to either ask openly on the > mailing list, or else contact the relevant person directly. > > Bifurcated Driver (Danny.Zhou at intel.com) > Packet Reordering/Packet Distributor (Bruce.Richardson at intel.com) > New Hardware Support (Walter.E.Gilmore at intel.com) > Fortville features (Heqing.Zhu at intel.com) > Support Multiple Threads per Core (Venky.Venkatesan at intel.com) > Cuckoo Hash (Bruce.Richardson at intel.com, Venky.Venkatesan at intel.com) > > The Cuckoo Hash paper that was mentioned is available at: > http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf. > > Finally, if anybody has suggestions for topics for future calls, please let > me know. > ABI versioning, in support of packaging the DPDK for non-rebuilding users. Neil > > Thanks, > Tim > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim > > Sent: Friday, October 31, 2014 3:35 PM > > To: 'dev at dpdk.org' > > Subject: Re: [dpdk-dev] DPDK Community Conference Call - Friday 31st > > October > > > > This is just a reminder for anybody who's interested that this will be on > > in 30 > > minutes, and that we'll be discussing the feature list for the DPDK 2.0 > > release > > in March 2015. > > > > Audio bridge details are: > > France: +33 1588 77298 > > Germany:+49 8999 143191 > > Israel: +972 2589 6577 > > Russia: +7 495 641 4663 > > UK: +44 1793 402663 > > USA/Canada: +1 916 356 2663 or +1-888-875-9370 > > > > Bridge: 5 > > Conference ID: 1264677285 > > > > > > Tim > > > > > -Original Message- > > > From: O'driscoll, Tim > > > Sent: Friday, October 24, 2014 10:22 AM > > > To: dev at dpdk.org > > > Subject: DPDK Community Conference Call - Friday 31st October > > > > > > We're planning to hold our first community conference call on Friday > > > 31st October. It's impossible to find a time that suits everybody, so > > > we've chosen to do this in the afternoon/evening in Europe, which is > > > the morning in the USA. This does unfortunately limit participation > > > from PRC, Japan and other parts of the world. Here's the time and date in > > > a > > variety of time zones: > > > > > > Dublin (Ireland) Friday, October 31, 2014 at > > > 4:00:00 PMGMT UTC > > > Paris (France)Friday, October 31, 2014 at > > > 5:00:00 > > > PMCET UTC+1 hour > > > San Francisco (U.S.A. - California) Friday, October 31, 2014 at > > > 9:00:00 > > > AMPDT UTC-7 hours > > > New York (U.S.A. - New York) Friday, October 31, 2014 at > > 12:00:00 > > > Noon EDT UTC-4 hours > > > Tel Aviv (Israel) Friday, October 31, 2014 at > > 6:00:00 > > > PMIST UTC+2 hours > > > Moscow (Russia) Friday, October 31, 2014 at 7:00:00 > > > PMMSK UTC+3 hours > > > > > > > > > Audio bridge details are: > > > France: +33 1588 77298 > > > Germany: +49 8999 143191 > > > Israel: +972 2589 6577 > > > Russia: +7 495 641 4663 > > > UK: +44 1793 402663 > > > USA: +1 916 356 2663 > > > > > > Bridge: 5 > > > Conference ID: 1264677285 > > > > > > If anybody needs an access number for another country, let me know. > > > > > > > > > Agenda: > > > Discuss feature list for DPDK 2.0 (Q1 2015). > > > Suggestions for topics for future calls. > > > > > > > > > Thanks, > > > Tim >
[dpdk-dev] Relationship between H/W ring and S/W ring
Now I understand. Thanks Bruce. 2014? 10? 31? 19:08? Bruce Richardson ?(?) ? ?: > On Fri, Oct 31, 2014 at 09:51:56AM +0900, Gyumin wrote: >> Thanks Bruce. >> >> I also agree with that the size of the S/W ring depends on the configuration >> parameters because the size of the S/W ring is /sizeof(struct igb_rx_entry) >> * len/ in the ixgbe_dev_rx_queue_setup function. H/W ring is also allocated >> in the same function by using the ring_dma_zone_reserve function, and its >> size is RX_RING_SZ. I don't think the RX_RING_SZ is configurable but it is >> fixed value. Is there any other code configuring the size of H/W ring? >> > Indeed you are right, my mistake. The comment indicates that we always reserve > the memory to be the maximum size so that we can resize the rings easier later > on. > In terms of runtime usage, though, if you look a the RX functions, you can see > that the two rings are always kept in sync. For example, looking at > ixgbe_rxq_rearm in ixgbe_rxtx_vec.c, you will see that rxdp and rxep values > both start at offset "rxq->rxrearm_start" at the top of the function, and that > in the main rearm loop, both are incremented twice each iteration (rxep += 2 > in > the for statment itself, and two rxdp++'s are used in the last two lines of > the > loop body). > > Regards, > /Bruce > >> 2014-10-30 ?? 6:55? Bruce Richardson ?(?) ? ?: >>> On Thu, Oct 30, 2014 at 04:32:16PM +0900, Gyumin wrote: Hi I`m reading the ixgbe code especially about H/W ring and S/W ring. Is the relationship between H/W ring and S/W ring one-to-one mapping? As far as I know, H/W ring size is determined in the code(hard coded) while S/W ring size is determined in port configuration time. In the ixgbe_rx_alloc_bufs function, H/W ring header address and packet address indicate the DMA address of S/W ring's mbuf. I understand it means that the relationship between the H/W ring and S/W ring is one-to-one mapping. For example, if the size of H/W ring is greater than the size of S/W ring then some portion of H/W ring is unused. Is it correct? Thanks >>> Hi, >>> >>> Yes, there is a 1:1 mapping between the hardware and software ring entries, >>> and both are sized depending on the configuration parameters passed to the >>> ring setup APIs. As you state, the HW ring contains the DMA addresses of >>> the packet buffers, while the sw_ring contains the pointers to the original >>> mbufs. The two rings are always kept in sync in the code. >>> >>> /Bruce >>>
[dpdk-dev] DPDK Community Conference Call - Friday 31st October
+1 for hangout Le 1 nov. 2014 13:59, "Neil Horman" a ?crit : > On Fri, Oct 31, 2014 at 05:36:59PM +, O'driscoll, Tim wrote: > > Thanks again to those who attended the call earlier. Hopefully people > found it useful. > > > > We'll schedule a follow-up call for 2 weeks' time. One thing that we do > want to look into is an easy way to allow screen sharing, so that we can > use some slides to guide the discussion. Internally within Intel we use MS > Lync. We can try that, but it's not always very user-friendly for external > participants, and doesn't have a Linux client. Other options would include > GoToMeeting or WebEx. If anybody has input on a good tool for this, let me > know. > > > Don't use Lync, its a horrid tool. As you note, there is no linux client > (nor a > mac client that I'm aware of). Google hangouts offers screen sharing, and > is > free for anyone to use. > > > We covered the following features from our 2.0 list today, and will > discuss the remainder on the next call. I've called out below who on our > side was describing each of the features, and included their email > addresses. If anybody has further questions on these, feel free to either > ask openly on the mailing list, or else contact the relevant person > directly. > > > > Bifurcated Driver (Danny.Zhou at intel.com) > > Packet Reordering/Packet Distributor (Bruce.Richardson at intel.com) > > New Hardware Support (Walter.E.Gilmore at intel.com) > > Fortville features (Heqing.Zhu at intel.com) > > Support Multiple Threads per Core (Venky.Venkatesan at intel.com) > > Cuckoo Hash (Bruce.Richardson at intel.com, Venky.Venkatesan at intel.com) > > > > The Cuckoo Hash paper that was mentioned is available at: > http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf. > > > > Finally, if anybody has suggestions for topics for future calls, please > let me know. > > > ABI versioning, in support of packaging the DPDK for non-rebuilding users. > > Neil > > > > > Thanks, > > Tim > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim > > > Sent: Friday, October 31, 2014 3:35 PM > > > To: 'dev at dpdk.org' > > > Subject: Re: [dpdk-dev] DPDK Community Conference Call - Friday 31st > > > October > > > > > > This is just a reminder for anybody who's interested that this will be > on in 30 > > > minutes, and that we'll be discussing the feature list for the DPDK > 2.0 release > > > in March 2015. > > > > > > Audio bridge details are: > > > France: +33 1588 77298 > > > Germany:+49 8999 143191 > > > Israel: +972 2589 6577 > > > Russia: +7 495 641 4663 > > > UK: +44 1793 402663 > > > USA/Canada: +1 916 356 2663 or +1-888-875-9370 > > > > > > Bridge: 5 > > > Conference ID: 1264677285 > > > > > > > > > Tim > > > > > > > -Original Message- > > > > From: O'driscoll, Tim > > > > Sent: Friday, October 24, 2014 10:22 AM > > > > To: dev at dpdk.org > > > > Subject: DPDK Community Conference Call - Friday 31st October > > > > > > > > We're planning to hold our first community conference call on Friday > > > > 31st October. It's impossible to find a time that suits everybody, so > > > > we've chosen to do this in the afternoon/evening in Europe, which is > > > > the morning in the USA. This does unfortunately limit participation > > > > from PRC, Japan and other parts of the world. Here's the time and > date in a > > > variety of time zones: > > > > > > > > Dublin (Ireland) Friday, October 31, 2014 at > > > > 4:00:00 PMGMT UTC > > > > Paris (France)Friday, October 31, 2014 > at 5:00:00 > > > > PMCET UTC+1 hour > > > > San Francisco (U.S.A. - California) Friday, October 31, 2014 > at 9:00:00 > > > > AMPDT UTC-7 hours > > > > New York (U.S.A. - New York) Friday, October 31, 2014 at > > > 12:00:00 > > > > Noon EDT UTC-4 hours > > > > Tel Aviv (Israel) Friday, October 31, 2014 at > > > 6:00:00 > > > > PMIST UTC+2 hours > > > > Moscow (Russia) Friday, October 31, 2014 at 7:00:00 > > > > PMMSK UTC+3 hours > > > > > > > > > > > > Audio bridge details are: > > > > France: +33 1588 77298 > > > > Germany: +49 8999 143191 > > > > Israel: +972 2589 6577 > > > > Russia: +7 495 641 4663 > > > > UK: +44 1793 402663 > > > > USA: +1 916 356 2663 > > > > > > > > Bridge: 5 > > > > Conference ID: 1264677285 > > > > > > > > If anybody needs an access number for another country, let me know. > > > > > > > > > > > > Agenda: > > > > Discuss feature list for DPDK 2.0 (Q1 2015). > > > > Suggestions for topics for future calls. > > > > > > > > > > > > Thanks, > > > > Tim > > >
[dpdk-dev] [PATCH] app/test: pci_autotest test fails if there is any device bound to igb_uio driver
Since commit a155d430119 ("support link bonding device initialization"),
rte_eal_pci_probe() is called in rte_eal_init().
pci_autotest called it to bind devices to the test_driver and test_driver2.
Therefore, the function is called twice and devices already allocated
will cause the test fail.
This patch solves that issue, unregistering all previous drivers before
calling rte_eal_pci_probe() for the first time, so DPDK does not try
to allocate data for the devices, binding them to their previous
drivers again.
Signed-off-by: Pablo de Lara
---
app/test/test_pci.c | 31 +--
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index e834c4d..4f0169a 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -39,10 +39,13 @@
#include
#include
+#include
#include
#include "test.h"
+/* Generic maximum number of drivers to have room to allocate all drivers */
+#define NUM_MAX_DRIVERS 256
/*
* PCI test
@@ -57,7 +60,6 @@
int test_pci_run = 0; /* value checked by the multiprocess test */
static unsigned pci_dev_count;
-static unsigned driver_registered = 0;
static int my_driver_init(struct rte_pci_driver *dr,
struct rte_pci_device *dev);
@@ -150,15 +152,22 @@ int
test_pci(void)
{
struct rte_devargs_list save_devargs_list;
+ struct rte_pci_driver *dr = NULL;
+ struct rte_pci_driver *save_pci_driver_list[NUM_MAX_DRIVERS];
+ unsigned i, num_drivers = 0;
printf("Dump all devices\n");
rte_eal_pci_dump(stdout);
- if (driver_registered == 0) {
- rte_eal_pci_register(&my_driver);
- rte_eal_pci_register(&my_driver2);
- driver_registered = 1;
+
+ /* Unregister all previous drivers */
+ TAILQ_FOREACH(dr, &pci_driver_list, next) {
+ rte_eal_pci_unregister(dr);
+ save_pci_driver_list[num_drivers++] = dr;
}
+ rte_eal_pci_register(&my_driver);
+ rte_eal_pci_register(&my_driver2);
+
pci_dev_count = 0;
printf("Scan bus\n");
rte_eal_pci_probe();
@@ -187,11 +196,13 @@ test_pci(void)
}
test_pci_run = 1;
- if (driver_registered == 1) {
- rte_eal_pci_unregister(&my_driver);
- rte_eal_pci_unregister(&my_driver2);
- driver_registered = 0;
- }
+
+ rte_eal_pci_unregister(&my_driver);
+ rte_eal_pci_unregister(&my_driver2);
+
+ /* Restore original driver list */
+ for (i = 0; i < num_drivers; i++)
+ rte_eal_pci_register(save_pci_driver_list[i]);
return 0;
}
--
1.7.4.1
[dpdk-dev] Fwd: FOSDEM conference - call for participation
Rather than individual talks what about getting them to schedule a 1/2 day unconference? On Fri, Oct 31, 2014 at 3:53 PM, Thomas Monjalon wrote: > Hi, > > Talks related to DPDK can be proposed for FOSDEM 2015: > https://fosdem.org/2015/ > This conference will take place in Belgium on 31 January & 1 February. > > -- > Thomas > > Forwarded Message > Subject: Network devroom call for participation > Date: Fri, 31 Oct 2014 17:33:33 -0400 > From: Dave Neary > To: Pavel Simerda , > network-devroom at lists.fosdem.org, fosdem at lists.fosdem.org > > Hi everyone, > > We are pleased to announce the Call for Participation in the FOSDEM > 2015 Networking DevRoom! > > Important dates: > * Nov 25: Deadline for submissions > * Dec 1: Speakers notified of acceptance > * Dec 5: Schedule published > > This is the first time that networking has been included as a > stand-alone DevRoom, and this year the topics will cover two distinct > fields: > * Software Defined Networking (SDN), covering virtual switching, open > source SDN controllers, virtual routing > * Network management, covering host-level networking - NetworkManager, > ConnMan, systemd, wicked, kernel network services, network security, etc > > > We are now inviting proposals for talks about Free/Libre/Open-source > Software on the topics of SDN and network management. This is an > exciting and growing field, and this is a unique opportunity to show > novel ideas and developments to a very knowledgeable technical audience. > > Topics accepted include, but are not limited to: > > SDN: > * SDN controllers - OpenDaylight, OpenContrail, OpenStack Neutron > * Dataplane processing: DPDK, OpenDataplane, netdev, netfilter > * Virtual switches: Open vSwitch, Snabb Switch, VDE > * Open network protocols: OpenFlow, NETCONF, OpenLISP > > Network management: > * Network management: NetworkManager, ConnMan, systemd-networkd, > interoperability among these projects > * Common code infrastructure: libnl, libmnl, libsystemd, ell, pyroute2 > * Network services: DHCP, DNS, DNSSEC, PPP > * Connection management: Wifi, tethering, connection sharing, metric and > source based routing, > > Talks should be aimed at a technical audience, but should not assume > that attendees are already familiar with your project or how it solves a > general problem. Talk proposals can be very specific solutions to a > problem, or can be higher level project overviews for lesser known > projects. > > Please include the following information when submitting a proposal: > > Your name > The title of your talk (please be descriptive, as titles will be > listed with around 250 from other projects) > Short abstract of one or two paragraphs > Short bio (with photo) > > The deadline for submissions is November 25th 2014. FOSDEM will be held > on the weekend of January 31st-February 1st 2015 and the Networking > DevRoom will take place on Saturday, January 31st 2015. Please use the > following website to submit your proposals: > https://penta.fosdem.org/submission/FOSDEM15 (you do not need to create > a new Pentabarf account if you already have one from past years). > > You can also join the devroom?s mailing list, which is the official > communication channel for the DevRoom: network-devroom at lists.fosdem.org > (subscription page: https://lists.fosdem.org/listinfo/network-devroom) > > ? The Networking DevRoom 2015 Organization Team > > -- > Dave Neary - NFV/SDN Community Strategy > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +1-978-399-2182 / Cell: +1-978-799-3338 >
[dpdk-dev] [PATCH RFC] Update/Improve build system
On Fri, Oct 31, 2014 at 10:45:07AM +, Gonzalez Monroy, Sergio wrote: > > From: Matthew Hall [mailto:mhall at mhcomputing.net] > > Sent: Thursday, October 30, 2014 8:50 PM > > > > On Thu, Oct 30, 2014 at 09:18:23AM +, Gonzalez Monroy, Sergio wrote: > > > I would say that D) is a good balance, although not being the simplest. > > > > A, or D. Depending on things such as, "If you run the DPDK on Random > > Platform X," where X could be something like Power CPUs or other weird > > stuff, will all of the things needed for the Combined Lib 1) be compilable, > > 2) > > be able to load w/o errors. > > > > For example, I could see probe ctor functions from various PMD's blowing up > > on unsupported hardware. Like how the rte_pmd_virtio had issues when I > > tried it on my VM system. > > > IMHO the underlying issue was that virtio was unsupported for that platform. > What I am trying to say is that any app built against a combined shared lib > or combined/separated > static lib will have that same issue if the feature/PMD is unsupported for > the platform. > In the virtio case, building against combined shared or combined/separated > static DPDK libs > would have the same result because the virtio PMD would be in the app. > > > If we think we can make sure no platform specific stuff breaks when it ends > > up in Combined Lib A then A is probably the easiest for all. > > > I agree, a combined lib would simplify all app/lib linking, making it easier > for the user and less error prone. > > One of the downsides that comes to mind is a flow work (I think you mentioned > it) where you > have multiple apps building against a single DPDK copy, and each app uses > different features/PMDs. > In that scenario, having separated libs would make your life easier as you > would not need to have > multiple DPDK copies customized for each app, giving you the flexibility to > hand pick each lib you > want to include into your app. > That flow work still presents some issues as they may be features that are > incompatible between > each other and would need to be in different DPDK copies. > It might be reasonable here to consider pmd's separately from the rest of the system, given that, they are supposed be built as isolated libraries that don't export any symbols. Some pmd's break that assumption, but they should really be fixed anyway. If you did that, you can build the dpdk as a single library, and build the pmds as separate libraries (shared or static). Neil > Regards, > Sergio > > > Matthew. >
