[dpdk-dev] GitHub sandbox for the DPDK community
On Fri, May 01, 2015 at 12:49:51PM -0700, Matthew Hall wrote: > On Fri, May 01, 2015 at 11:09:14AM -0700, Stephen Hemminger wrote: > > With email, the patches are right in front of developers and easier to quote > > for review comments. > > Right in front of that subset of developers who do everything kernel-style, > perhaps yes. But this sort of workflow is in the minority these days, pretty > much every other project I've worked on besides the kernel used graphical > merging tools for this to make things easier to follow for the uninitiated. Projects like GCC, GLIBC, binutils, busybox, etc or what? A.
[dpdk-dev] DPDK Community Call - Beyond DPDK 2.0
There's been a good discussion on the mailing list on the Beyond DPDK 2.0 thread. To supplement this, we'd like to have a community call for people to air their views, and to help progress things towards a conclusion. It'll be an open format, so people can bring up whatever issues they want, but some topics for discussion might include: - Decision-making process. What do we do if issues don't reach a conclusion on the mailing list? Does stalemate just mean no change, or do we need some other mechanism to decide? A good example of an issue that may not reach a clear conclusion is the proposal move to github, where some seem to be in favour and others against. - How do we encourage more contributors to DPDK? - What tool/process improvements do we need to make? Further discussion of github is one obvious example. GoToMeeting Details: Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/556212525 You can also dial in using your phone. Ireland +353 (0) 19 030 010 Access Code: 556-212-525 More phone numbers United States (Long distance): +1 (646) 749-3129 Australia (Long distance): +61 2 8355 1020 Austria (Long distance): +43 (0) 7 2088 1047 Belgium (Long distance): +32 (0) 28 08 4368 Canada (Long distance): +1 (647) 497-9353 Denmark (Long distance): +45 (0) 69 91 89 28 Finland (Long distance): +358 (0) 942 59 7850 France (Long distance): +33 (0) 170 950 594 Germany (Long distance): +49 (0) 692 5736 7317 Italy (Long distance): +39 0 247 92 13 01 Netherlands (Long distance): +31 (0) 208 080 219 New Zealand (Long distance): +64 (0) 9 280 6302 Norway (Long distance): +47 75 80 32 07 Spain (Long distance): +34 911 82 9906 Sweden (Long distance): +46 (0) 852 500 186 Switzerland (Long distance): +41 (0) 435 0167 13 United Kingdom (Long distance): +44 (0) 330 221 0088 Here's the time in a variety of time zones: Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00 AM PDT UTC-7 hours Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST UTC-7 hours Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 hours New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 hours Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 hours London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00 PM BST UTC+1 hour Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3 hours Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST UTC+5:30 hours Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at 11:00:00 PM CST UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00
[dpdk-dev] GitHub sandbox for the DPDK community
Hi, On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote: > > - GitHub manages the patches via pull requests and can be easily seen > > via a web browser. > > - The down side is you do have to use a web browser to do some work, but > > the bulk of the everyday work would be done as it is today. > > - I think we all have a web browser now :-) > Yes, but as you said above, using a web browser doesn't make reviewing patches > faster. In fact, I would assert that it slows the process down, as it > prevents quick, easy command line access to patch review (as you have with a > properly configured MUA). That seems like we're going in the opposite > direction of at least one problem we would like to solve. I agree. Having a web browser interface for reviews etc. is acceptable only if people can still continue to use e-mail if they prefer. I don't know how github works in this regard but patches should still appear on the mailing list and it should be still possible to comment them via mailing list. A.
[dpdk-dev] GitHub sandbox for the DPDK community
On 5/1/15, 1:48 PM, "Neil Horman" wrote: >On Fri, May 01, 2015 at 10:31:08AM -0700, Matthew Hall wrote: >> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote: >> > Yes, but as you said above, using a web browser doesn't make >>reviewing patches >> > faster. In fact, I would assert that it slows the process down, as >>it prevents >> > quick, easy command line access to patch review (as you have with a >>properly >> > configured MUA). That seems like we're going in the opposite >>direction of at >> > least one problem we would like to solve. >> >> Normally I'm a big command-line supporter. However I have found >>reviewing >> patches by email for me is about the most painful workflow. >> >> The emails are pages and pages. >> >So collapse the quoted text (see below) > >> The replies from commenters are buried in the walls of text. >> >Again, collapse the text, many MUA's let you do that, its not a feature >unique >to github. > >> Replies to replies keep shifting farther off the edge of the screen. >>The code >> gets weirder and weirder to try to read. >> >Text Collapse will reformat that for you. > >> Quickly reading over the patchset by scrolling through to get the >>flavor of >> it, to see if I'm qualified to review it, and look at the parts I >>actually >> know about is much harder. >> >Thats what the origional post is for, no? Look at that to determine if >you are >qualified to read it. > >> I can go to one place to see every candidate patchset out there, the GH >>Pull >> Request page. Then I can just sync up the branch and test it on my own >>systems >> to see if it works, not just try to read it. >> >how is that different from a mailing list? both let you search for >posts, and >both allow you to sync git branches (github via git remote/pull, mailing >list >via git am) > >> Github automatically minimizes old comments that are already fixed, so >>they >> don't keep consuming space and mental bandwidth from the review. >An MUA can do that too. IIRC evolution and thunderbird both have collapse >features. I'm sure others do too. Not all email clients allow for collapsing threads, I am using outlook for Mac and I do not think the windows version has that feature. I am not sure Apple mail client can handle collapsing or not as I am stuck with outlook as my email virus (I mean client) :-) The point here is all emails clients have different ways of displaying the information some good some bad. I see the GitHub method to be different, but for me I am able to understand the way it handles comments and patches. I have the same problems as Matthew, but I do not want to get into a email client wars. > >> >> All in all, I'd be able to review more DPDK patches faster with the GH >> interface than having them in the mailing list. >> >> Matthew. >>
[dpdk-dev] DPDK Community Call - Beyond DPDK 2.0
Hi Tim, When were you thinking of having the call? It's not been explicit, but can I assume that this call will also be promoted among potential supporters of the project who may not be on this list? I would be interested to get the perspective from the people who are perhaps not developers who decide whether their organization engages strategically with a project or not. Thanks, Dave. On 05/01/2015 06:20 PM, O'Driscoll, Tim wrote: > There's been a good discussion on the mailing list on the Beyond DPDK 2.0 > thread. To supplement this, we'd like to have a community call for people to > air their views, and to help progress things towards a conclusion. It'll be > an open format, so people can bring up whatever issues they want, but some > topics for discussion might include: > - Decision-making process. What do we do if issues don't reach a conclusion > on the mailing list? Does stalemate just mean no change, or do we need some > other mechanism to decide? A good example of an issue that may not reach a > clear conclusion is the proposal move to github, where some seem to be in > favour and others against. > - How do we encourage more contributors to DPDK? > - What tool/process improvements do we need to make? Further discussion of > github is one obvious example. > > GoToMeeting Details: > Please join my meeting from your computer, tablet or smartphone. > https://global.gotomeeting.com/join/556212525 > > You can also dial in using your phone. > Ireland +353 (0) 19 030 010 > > Access Code: 556-212-525 > > More phone numbers > United States (Long distance): +1 (646) 749-3129 > Australia (Long distance): +61 2 8355 1020 > Austria (Long distance): +43 (0) 7 2088 1047 > Belgium (Long distance): +32 (0) 28 08 4368 > Canada (Long distance): +1 (647) 497-9353 > Denmark (Long distance): +45 (0) 69 91 89 28 > Finland (Long distance): +358 (0) 942 59 7850 > France (Long distance): +33 (0) 170 950 594 > Germany (Long distance): +49 (0) 692 5736 7317 > Italy (Long distance): +39 0 247 92 13 01 > Netherlands (Long distance): +31 (0) 208 080 219 > New Zealand (Long distance): +64 (0) 9 280 6302 > Norway (Long distance): +47 75 80 32 07 > Spain (Long distance): +34 911 82 9906 > Sweden (Long distance): +46 (0) 852 500 186 > Switzerland (Long distance): +41 (0) 435 0167 13 > United Kingdom (Long distance): +44 (0) 330 221 0088 > > Here's the time in a variety of time zones: > Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour > San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00 AM PDT > UTC-7 hours > Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST UTC-7 > hours > Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM EDT > UTC-4 hours > New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 > hours > Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 > hours > London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00 PM BST > UTC+1 hour > Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours > Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3 hours > Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours > New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST UTC+5:30 > hours > Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at 11:00:00 > PM CST > UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00 > > -- 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] GitHub sandbox for the DPDK community
On 5/1/15, 1:09 PM, "Stephen Hemminger" wrote: >On Fri, 1 May 2015 15:56:32 + >"Wiles, Keith" wrote: > >> Hi Everyone, >> >> I believe the DPDK community would benefit from moving to GitHub as the >> primary DPDK site. http://github.com >> >> I believe the DPDK community can benefit from being at a very well know >> world wide site. GitHub seems to have the most eyes of any of the open >> source Git repos today and it appears they have more then twice as many >> developers. GitHub has a number of features I see as some good >>additions to >> our community using the GitHub organization account type. >> >> The cost for an organization account is $0 as long as we do not need >>more >> then 5 private repos. 10 private repos is $25/month and had other plans >> for more. I do not see us needing more then 5 private repos today and >>the >> only reason I can see having a private repo is to do some prep work on >>the >> repo before making public. Every contributor would need to create a >>GitHub >> personal account, which is at no cost unless you need more then 5 >>private >> repos. In both accounts you can have unlimited public repos. >> >> >>https://help.github.com/articles/where-can-i-find-open-source-projects-to >>-w >> ork-on/ >> >> http://www.sitepoint.com/using-git-open-source-projects/ >> >> - Adding more committers can lead to a security problems for 6Wind (I >> assume). >> - 6Wind appearing to own DPDK.org is not a good message to the >>community. >> - Not assuming 6Wind?s dpdk.org site will disappear only where the >> community stores the master repos and how the community interacts with >>the >> master. >> - Permission and access levels in dpdk.org is only one level and we can >> benefit from having 4 levels and teams as well. >> - The patch process today suffers from timely reviews, which will not be >> fixed by moving. >> - GitHub has a per pull request discussions area, which gives a clean >> way to review all discussions on a specific change. >> - The current patch model is clone/modify/commit/send patch set >> - The model with GitHub is fork on GitHub/modify/commit/send pull >> request >> - The patchwork web site is reasonable, but has some draw backs in >> maintaining the site. >> - GitHub manages the patches via pull requests and can be easily seen >> via a web browser. >> - The down side is you do have to use a web browser to do some work, >>but >> the bulk of the everyday work would be done as it is today. >> - I think we all have a web browser now :-) >> - GitHub has team support and gives a group better control plus >> collaboration is much easier as we have a external location to work. >> - Most companies have some pretty high security level and being to >> collaborate between two or more companies is very difficult if one >>company >> is hosting the repo behind a firewall. >> - Using GitHub and teams would make collaboration a lot easier or >> collaboration between two or more user accounts as well. >> - GitHub has a Web Page system, which can be customized for the >>community >> needs via a public or private repo. >> - We still need a dpdk.org email list I believe as I did not find one at >> GitHub. >> - We can also forward GitHub emails to the list. >> - I believe you can reply to an email from GitHub and the email will >>get >> appended to the discussion thread. >> > >In my experience the github pull model causes less review, not more. >It only works if maintainers are motivated to do this as their full time >job. > >With email, the patches are right in front of developers and easier to >quote >for review comments. We are not getting the eyes on the review today, which means to me it will not matter if we move to GitHub method in the future. Personally I am able to see the differences with the GitHub display and helps me see what is really happening. The emails are too flat and then they can indent forever or someones email client (like mine) screws up the format. With the GitHub method is will be exactly the same for everyone. >
[dpdk-dev] GitHub sandbox for the DPDK community
On 5/1/15, 11:45 AM, "Neil Horman" wrote: >On Fri, May 01, 2015 at 03:56:32PM +, Wiles, Keith wrote: >> Hi Everyone, >> >> I believe the DPDK community would benefit from moving to GitHub as the >> primary DPDK site. http://github.com >> >I'm not explicitly opposed to this, but I'm having trouble matching up the >technical and governance issues raised on the list as of late with the >benefits >you indicate github provides. Thoughts inline. > >> I believe the DPDK community can benefit from being at a very well know >> world wide site. GitHub seems to have the most eyes of any of the open >> source Git repos today and it appears they have more then twice as many >> developers. GitHub has a number of features I see as some good >>additions to >> our community using the GitHub organization account type. >> > >Do you think that the current site dpdk.org lacks visibility? Do we have >analytics on the site, or anecdotal evidence to suggest that more >visiblity can >be had by moving to github? It seems to me that people in search of a >dataplane >library google it, and dpdk is in the top 10 results, along with its >wikipedia >page, etc: >https://www.google.com/#q=dataplane+library > >Not sure how using github brings on additional visibility. Google is a great tool, you can find anything in the world with Google and will continue to be how most find items on the web. Being able to use Google is not the right question here you should be asking. The question is how do we promote and get higher visitability for the DPDK community? I believe moving DPDK.org to a well known location and a well known open source location should be a benefit for the DPDK community as a whole. If you are using GitHub today then I think you understand this point already. > > >> The cost for an organization account is $0 as long as we do not need >>more >> then 5 private repos. 10 private repos is $25/month and had other plans >> for more. I do not see us needing more then 5 private repos today and >>the >> only reason I can see having a private repo is to do some prep work on >>the >> repo before making public. Every contributor would need to create a >>GitHub >> personal account, which is at no cost unless you need more then 5 >>private >> repos. In both accounts you can have unlimited public repos. >> > >Given that dpdk is a public project, why would we need _any_ private >repositories? They should all be public, no? Private repos (5) of them come for free and I pointed out the only reason I thought we needed one as a temporary place for a repo before making public. I agree we do not really need them and all repos should be public. > >> >>https://help.github.com/articles/where-can-i-find-open-source-projects-to >>-w >> ork-on/ >> >> http://www.sitepoint.com/using-git-open-source-projects/ >> >> - Adding more committers can lead to a security problems for 6Wind (I >> assume). >In what way? Are you advocating for a single comitter here, and how does >Github >provide that? FWIW, I think subtree maintainers is an excellent strategy >for >more efficient workflow (getting patches accepted faster has been an >identified >problem), and allowing subtree maintainers with a comitter for each is a >good >way to solve that. Thats implementable with github or any other git based >solution, mind you, so its neither an argument for or against github. Maybe you mis-read this point. I am not suggesting only one committer, what I am suggesting is adding committers and logins to a 6Wind controlled machine could be a security issue for 6Wind. Maybe not, but moving to GitHub removes any possible hacks to 6Wind is my belief and possible liability issues for 6Wind. This was a very minor point. As for multiple subtrees can quickly and easily be added to GitHub and you could even make this happen if you want to be one of the persons helping build the GitHub site. From other GitHub sites I see a lot of repos and sub repos to the primary tree and personally I agree having a few more subtrees will not effect DPDK and could possible help define teams around these subtrees. > >> - 6Wind appearing to own DPDK.org is not a good message to the >>community. >Why not? They're graciously hosting the site, and not advertizing on it >(at >least they shouldn't be, and I don't it egregiously displayed). Netcraft >will >show you lots of open source projects that host their site on a server >operated >by a participating company. Care has to be taken about bias, but its not >uncommon. I do not believe the point is around if 6Wind loans us machines and storage and internet connect bandwidth. My point is GitHub is big company and they have a lot of resources to make sure everyone remains connected to the repo(s), Backups, support, tools and any number of other items to make the DPDK community better in the long run. I believe it comes down to resources and freeing up resources for 6Wind by moving to a bigger company which is its sole job is to host
[dpdk-dev] GitHub sandbox for the DPDK community
On 5/1/15, 12:31 PM, "Matthew Hall" wrote: >Normally I'm a big command-line supporter. However I have found reviewing >patches by email for me is about the most painful workflow. > >The emails are pages and pages. > >The replies from commenters are buried in the walls of text. > >Replies to replies keep shifting farther off the edge of the screen. The >code >gets weirder and weirder to try to read. > >Quickly reading over the patchset by scrolling through to get the flavor >of >it, to see if I'm qualified to review it, and look at the parts I >actually >know about is much harder. > >I can go to one place to see every candidate patchset out there, the GH >Pull >Request page. Then I can just sync up the branch and test it on my own >systems >to see if it works, not just try to read it. > >Github automatically minimizes old comments that are already fixed, so >they >don't keep consuming space and mental bandwidth from the review. > >All in all, I'd be able to review more DPDK patches faster with the GH >interface than having them in the mailing list. +1 and very well stated. > >Matthew. >
[dpdk-dev] [RFC PATCH] librte_pmd_virtio: add support for PCI Port Hotplug
This patch depends on the Port Hotplug Framework.
It implements the eth_dev_uninit_t() function for virtio pmd.
Signed-off-by: Bernard Iremonger
---
lib/librte_pmd_virtio/virtio_ethdev.c | 39 -
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c
b/lib/librte_pmd_virtio/virtio_ethdev.c
index e63dbfb..3c4691f 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -63,6 +63,7 @@
static int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
+static int eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev);
static int virtio_dev_configure(struct rte_eth_dev *dev);
static int virtio_dev_start(struct rte_eth_dev *dev);
static void virtio_dev_stop(struct rte_eth_dev *dev);
@@ -1237,12 +1238,48 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
return 0;
}
+
+
+static int
+eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
+{
+ struct rte_pci_device *pci_dev;
+ struct virtio_hw *hw = eth_dev->data->dev_private;
+
+ if (rte_eal_process_type() == RTE_PROC_SECONDARY)
+ return -EPERM;
+
+ if (hw->started == 1) {
+ virtio_dev_stop(eth_dev);
+ virtio_dev_close(eth_dev);
+ }
+ pci_dev = eth_dev->pci_dev;
+
+ eth_dev->dev_ops = NULL;
+ eth_dev->tx_pkt_burst = NULL;
+ eth_dev->rx_pkt_burst = NULL;
+
+ /* Allocate memory for storing MAC addresses */
+ rte_free(eth_dev->data->mac_addrs);
+ eth_dev->data->mac_addrs = NULL;
+
+ /* reset interrupt callback */
+ if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
+ rte_intr_callback_unregister(&pci_dev->intr_handle,
+ virtio_interrupt_handler, eth_dev);
+
+ return 0;
+}
+
+
static struct eth_driver rte_virtio_pmd = {
{
.name = "rte_virtio_pmd",
.id_table = pci_id_virtio_map,
+ .drv_flags = RTE_PCI_DRV_DETACHABLE,
},
.eth_dev_init = eth_virtio_dev_init,
+ .eth_dev_uninit = eth_virtio_dev_uninit,
.dev_private_size = sizeof(struct virtio_hw),
};
--
1.7.4.1
[dpdk-dev] [PATCH] eal: whitespace cleanup
Go through the linuxapp eal code and cleanup whitespace
issues reported by checkpatch.
---
lib/librte_eal/linuxapp/eal/eal_alarm.c | 17 ++--
lib/librte_eal/linuxapp/eal/eal_debug.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 57 ++---
lib/librte_eal/linuxapp/eal/eal_interrupts.c| 26 +++---
lib/librte_eal/linuxapp/eal/eal_ivshmem.c | 76 -
lib/librte_eal/linuxapp/eal/eal_lcore.c | 5 +-
lib/librte_eal/linuxapp/eal/eal_memory.c| 103 +---
lib/librte_eal/linuxapp/eal/eal_pci.c | 25 +++---
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 12 ++-
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 3 +-
lib/librte_eal/linuxapp/eal/eal_timer.c | 11 +--
lib/librte_eal/linuxapp/eal/eal_xen_memory.c| 41 +-
12 files changed, 199 insertions(+), 179 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_alarm.c
b/lib/librte_eal/linuxapp/eal/eal_alarm.c
index a0eae1e..762f162 100644
--- a/lib/librte_eal/linuxapp/eal/eal_alarm.c
+++ b/lib/librte_eal/linuxapp/eal/eal_alarm.c
@@ -97,16 +97,17 @@ error:
static void
eal_alarm_callback(struct rte_intr_handle *hdl __rte_unused,
- void *arg __rte_unused)
+ void *arg __rte_unused)
{
struct timeval now;
struct alarm_entry *ap;
rte_spinlock_lock(&alarm_list_lk);
- while ((ap = LIST_FIRST(&alarm_list)) !=NULL &&
- gettimeofday(&now, NULL) == 0 &&
- (ap->time.tv_sec < now.tv_sec || (ap->time.tv_sec ==
now.tv_sec &&
- ap->time.tv_usec <=
now.tv_usec))){
+ while ((ap = LIST_FIRST(&alarm_list)) != NULL &&
+ gettimeofday(&now, NULL) == 0 &&
+ (ap->time.tv_sec < now.tv_sec ||
+ (ap->time.tv_sec == now.tv_sec &&
+ap->time.tv_usec <= now.tv_usec))){
ap->executing = 1;
ap->executing_id = pthread_self();
rte_spinlock_unlock(&alarm_list_lk);
@@ -162,7 +163,7 @@ rte_eal_alarm_set(uint64_t us, rte_eal_alarm_callback
cb_fn, void *cb_arg)
rte_spinlock_lock(&alarm_list_lk);
if (!handler_registered) {
ret |= rte_intr_callback_register(&intr_handle,
- eal_alarm_callback, NULL);
+ eal_alarm_callback, NULL);
handler_registered = (ret == 0) ? 1 : 0;
}
@@ -171,8 +172,8 @@ rte_eal_alarm_set(uint64_t us, rte_eal_alarm_callback
cb_fn, void *cb_arg)
else {
LIST_FOREACH(ap, &alarm_list, next) {
if (ap->time.tv_sec > new_alarm->time.tv_sec ||
- (ap->time.tv_sec ==
new_alarm->time.tv_sec &&
- ap->time.tv_usec >
new_alarm->time.tv_usec)){
+ (ap->time.tv_sec == new_alarm->time.tv_sec &&
+ap->time.tv_usec > new_alarm->time.tv_usec)){
LIST_INSERT_BEFORE(ap, new_alarm, next);
break;
}
diff --git a/lib/librte_eal/linuxapp/eal/eal_debug.c
b/lib/librte_eal/linuxapp/eal/eal_debug.c
index 44fc4f3..c825057 100644
--- a/lib/librte_eal/linuxapp/eal/eal_debug.c
+++ b/lib/librte_eal/linuxapp/eal/eal_debug.c
@@ -56,7 +56,7 @@ void rte_dump_stack(void)
while (size > 0) {
rte_log(RTE_LOG_ERR, RTE_LOGTYPE_EAL,
"%d: [%s]\n", size, symb[size - 1]);
- size --;
+ size--;
}
}
diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index 028e309..4d4e226 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -65,7 +65,7 @@ static int32_t
get_num_hugepages(const char *subdir)
{
char path[PATH_MAX];
- long unsigned resv_pages, num_pages = 0;
+ unsigned long resv_pages, num_pages = 0;
const char *nr_hp_file;
const char *nr_rsvd_file = "resv_hugepages";
@@ -112,8 +112,8 @@ get_default_hp_size(void)
FILE *fd = fopen(proc_meminfo, "r");
if (fd == NULL)
rte_panic("Cannot open %s\n", proc_meminfo);
- while(fgets(buffer, sizeof(buffer), fd)){
- if (strncmp(buffer, str_hugepagesz, hugepagesz_len) == 0){
+ while (fgets(buffer, sizeof(buffer), fd)) {
+ if (strncmp(buffer, str_hugepagesz, hugepagesz_len) == 0) {
size = rte_str_to_size(&buffer[hugepagesz_len]);
break;
}
@@ -152,7 +152,7 @@ get_hugepage_dir(uint64_t hugepage_sz)
if (default_size == 0)
default_size = get_default_hp_size();
- while (fgets(buf, sizeof(bu
[dpdk-dev] GitHub sandbox for the DPDK community
Hi Everyone, I believe the DPDK community would benefit from moving to GitHub as the primary DPDK site. http://github.com I believe the DPDK community can benefit from being at a very well know world wide site. GitHub seems to have the most eyes of any of the open source Git repos today and it appears they have more then twice as many developers. GitHub has a number of features I see as some good additions to our community using the GitHub organization account type. The cost for an organization account is $0 as long as we do not need more then 5 private repos. 10 private repos is $25/month and had other plans for more. I do not see us needing more then 5 private repos today and the only reason I can see having a private repo is to do some prep work on the repo before making public. Every contributor would need to create a GitHub personal account, which is at no cost unless you need more then 5 private repos. In both accounts you can have unlimited public repos. https://help.github.com/articles/where-can-i-find-open-source-projects-to-w ork-on/ http://www.sitepoint.com/using-git-open-source-projects/ - Adding more committers can lead to a security problems for 6Wind (I assume). - 6Wind appearing to own DPDK.org is not a good message to the community. - Not assuming 6Wind?s dpdk.org site will disappear only where the community stores the master repos and how the community interacts with the master. - Permission and access levels in dpdk.org is only one level and we can benefit from having 4 levels and teams as well. - The patch process today suffers from timely reviews, which will not be fixed by moving. - GitHub has a per pull request discussions area, which gives a clean way to review all discussions on a specific change. - The current patch model is clone/modify/commit/send patch set - The model with GitHub is fork on GitHub/modify/commit/send pull request - The patchwork web site is reasonable, but has some draw backs in maintaining the site. - GitHub manages the patches via pull requests and can be easily seen via a web browser. - The down side is you do have to use a web browser to do some work, but the bulk of the everyday work would be done as it is today. - I think we all have a web browser now :-) - GitHub has team support and gives a group better control plus collaboration is much easier as we have a external location to work. - Most companies have some pretty high security level and being to collaborate between two or more companies is very difficult if one company is hosting the repo behind a firewall. - Using GitHub and teams would make collaboration a lot easier or collaboration between two or more user accounts as well. - GitHub has a Web Page system, which can be customized for the community needs via a public or private repo. - We still need a dpdk.org email list I believe as I did not find one at GitHub. - We can also forward GitHub emails to the list. - I believe you can reply to an email from GitHub and the email will get appended to the discussion thread. As most do not like to read long emails :-) I will stop here and add one more thing. I believe moving to GitHub for the DPDK community has a lot of advantages, but I also understand it will be different process and will cause a bit of issues as we convert. Having more eyes plus in a well know public location plus utilizing the extra features on Github plus a better public modifiable web pages is a few big advantages for the DPDK community. I have create a sandbox on GitHub for anyone to play with using GitHub. You will need to create a GitHub account and an email me your account name to add you to the organization site as a contributor. The GitHub site is not a fork of dpdk.org only a sandbox to play with how GitHub can help the community to gain more developers in a clean manner. https://github.com/dpdk-org Regards ++Keith
[dpdk-dev] [RFC PATCH] librte_pmd_bond: add support for PCI Port Hotplug
This patch depends on the Port Hotplug Framework.
It implements the rte_dev_uninit_t() function for the link bonding pmd.
Signed-off-by: Bernard Iremonger
---
lib/librte_pmd_bond/rte_eth_bond.h | 13 -
lib/librte_pmd_bond/rte_eth_bond_api.c | 84
lib/librte_pmd_bond/rte_eth_bond_pmd.c | 23 +++-
lib/librte_pmd_bond/rte_eth_bond_private.h |5 +-
4 files changed, 97 insertions(+), 28 deletions(-)
diff --git a/lib/librte_pmd_bond/rte_eth_bond.h
b/lib/librte_pmd_bond/rte_eth_bond.h
index d688fc3..8efbf07 100644
--- a/lib/librte_pmd_bond/rte_eth_bond.h
+++ b/lib/librte_pmd_bond/rte_eth_bond.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -131,6 +131,17 @@ int
rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id);
/**
+ * Free a bonded rte_eth_dev device
+ *
+ * @param name Name of the link bonding device.
+ *
+ * @return
+ * 0 on success, negative value otherwise
+ */
+int
+rte_eth_bond_free(const char *name);
+
+/**
* Add a rte_eth_dev device as a slave to the bonded device
*
* @param bonded_port_id Port ID of bonded device.
diff --git a/lib/librte_pmd_bond/rte_eth_bond_api.c
b/lib/librte_pmd_bond/rte_eth_bond_api.c
index e91a623..b91ef24 100644
--- a/lib/librte_pmd_bond/rte_eth_bond_api.c
+++ b/lib/librte_pmd_bond/rte_eth_bond_api.c
@@ -44,6 +44,13 @@
#define DEFAULT_POLLING_INTERVAL_10_MS (10)
+static struct eth_driver rte_bond_pmd = {
+ .pci_drv = {
+ .name = "rte_bond_pmd",
+ .drv_flags = RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
+ },
+};
+
int
valid_bonded_ethdev(struct rte_eth_dev *eth_dev)
{
@@ -193,6 +200,7 @@ number_of_sockets(void)
}
const char *driver_name = "Link Bonding PMD";
+static struct rte_pci_id pci_id_table = {0};
int
rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id)
@@ -200,9 +208,8 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
struct rte_pci_device *pci_dev = NULL;
struct bond_dev_private *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;
- struct eth_driver *eth_drv = NULL;
struct rte_pci_driver *pci_drv = NULL;
- struct rte_pci_id *pci_id_table = NULL;
+
/* now do all data allocation - for eth_dev structure, dummy pci driver
* and internal (private) data
*/
@@ -224,26 +231,14 @@ rte_eth_bond_create(const char *name, uint8_t mode,
uint8_t socket_id)
goto err;
}
- eth_drv = rte_zmalloc_socket(name, sizeof(*eth_drv), 0, socket_id);
- if (eth_drv == NULL) {
- RTE_BOND_LOG(ERR, "Unable to malloc eth_drv on socket");
- goto err;
- }
+ pci_drv = &rte_bond_pmd.pci_drv;
- pci_drv = ð_drv->pci_drv;
+ pci_id_table.device_id = PCI_ANY_ID;
+ pci_id_table.subsystem_device_id = PCI_ANY_ID;
+ pci_id_table.vendor_id = PCI_ANY_ID;
+ pci_id_table.subsystem_vendor_id = PCI_ANY_ID;
- pci_id_table = rte_zmalloc_socket(name, sizeof(*pci_id_table), 0,
socket_id);
- if (pci_id_table == NULL) {
- RTE_BOND_LOG(ERR, "Unable to malloc pci_id_table on socket");
- goto err;
- }
- pci_id_table->device_id = PCI_ANY_ID;
- pci_id_table->subsystem_device_id = PCI_ANY_ID;
- pci_id_table->vendor_id = PCI_ANY_ID;
- pci_id_table->subsystem_vendor_id = PCI_ANY_ID;
-
- pci_drv->id_table = pci_id_table;
- pci_drv->drv_flags = RTE_PCI_DRV_INTR_LSC;
+ pci_drv->id_table = &pci_id_table;
internals = rte_zmalloc_socket(name, sizeof(*internals), 0, socket_id);
if (internals == NULL) {
@@ -260,8 +255,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
pci_dev->numa_node = socket_id;
pci_drv->name = driver_name;
-
- eth_dev->driver = eth_drv;
+ eth_dev->driver = &rte_bond_pmd;
eth_dev->data->dev_private = internals;
eth_dev->data->nb_rx_queues = (uint16_t)1;
eth_dev->data->nb_tx_queues = (uint16_t)1;
@@ -317,13 +311,55 @@ rte_eth_bond_create(const char *name, uint8_t mode,
uint8_t socket_id)
err:
rte_free(pci_dev);
- rte_free(pci_id_table);
- rte_free(eth_drv);
rte_free(internals);
+ rte_free(eth_dev->data->mac_addrs);
return -1;
}
+int
+rte_eth_bond_free(const char *name)
+{
+ struct rte_eth_dev *eth_dev = NULL;
+ struct bond_dev_private *internals = NULL;
+
+ /* now free all data allocation - for eth_dev structure,
+* dummy pci driver and internal (private) data
+*/
+
+ /* find an ethdev entry */
+ eth_dev = rte_eth_dev_
[dpdk-dev] GitHub sandbox for the DPDK community
On Fri, May 01, 2015 at 10:31:08AM -0700, Matthew Hall wrote: > On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote: > > Yes, but as you said above, using a web browser doesn't make reviewing > > patches > > faster. In fact, I would assert that it slows the process down, as it > > prevents > > quick, easy command line access to patch review (as you have with a properly > > configured MUA). That seems like we're going in the opposite direction of > > at > > least one problem we would like to solve. > > Normally I'm a big command-line supporter. However I have found reviewing > patches by email for me is about the most painful workflow. > > The emails are pages and pages. > So collapse the quoted text (see below) > The replies from commenters are buried in the walls of text. > Again, collapse the text, many MUA's let you do that, its not a feature unique to github. > Replies to replies keep shifting farther off the edge of the screen. The code > gets weirder and weirder to try to read. > Text Collapse will reformat that for you. > Quickly reading over the patchset by scrolling through to get the flavor of > it, to see if I'm qualified to review it, and look at the parts I actually > know about is much harder. > Thats what the origional post is for, no? Look at that to determine if you are qualified to read it. > I can go to one place to see every candidate patchset out there, the GH Pull > Request page. Then I can just sync up the branch and test it on my own > systems > to see if it works, not just try to read it. > how is that different from a mailing list? both let you search for posts, and both allow you to sync git branches (github via git remote/pull, mailing list via git am) > Github automatically minimizes old comments that are already fixed, so they > don't keep consuming space and mental bandwidth from the review. An MUA can do that too. IIRC evolution and thunderbird both have collapse features. I'm sure others do too. > > All in all, I'd be able to review more DPDK patches faster with the GH > interface than having them in the mailing list. > > Matthew. >
[dpdk-dev] GitHub sandbox for the DPDK community
On Fri, May 01, 2015 at 10:59:32PM +0300, Aaro Koskinen wrote: > Projects like GCC, GLIBC, binutils, busybox, etc or what? > > A. You'll notice all of these are low-level UNIX hacker sorts of tools mostly, with the partial exception of busybox. But even that is mainly for embedded use. It doesn't mean I don't think they're good and useful, but it does limit the possible size of the community in my view. Since we are talking about how to get the largest widest community possible for DPDK, it could require doing things a bit differently from how many low-level tools have historically done things. The most popular projects in Github have up to 80K watchers, and 100K forks. This type of popularity and interest is going to be hard to match just doing it the older way only. Even Google said so, when they shut down Google Code and moved stuff to Github: http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html If we want to shoot for a big audience we have to make sure we have a presence where the eyeballs are focused, as well as finding a way to support the traditional kernel-style workflow some of the core contributors use. Matthew.
[dpdk-dev] GitHub sandbox for the DPDK community
On Fri, May 01, 2015 at 11:09:14AM -0700, Stephen Hemminger wrote: > With email, the patches are right in front of developers and easier to quote > for review comments. Right in front of that subset of developers who do everything kernel-style, perhaps yes. But this sort of workflow is in the minority these days, pretty much every other project I've worked on besides the kernel used graphical merging tools for this to make things easier to follow for the uninitiated. The GH pull requests are more friendly to all the non-kernel-style developers we're saying in these threads that we are hoping to get more involved in DPDK. I use DPDK on purpose because I don't want the ultimate purpose of my application to be getting into the middle of huge hard-to-read hard-to-follow threads, core-kernel flamewars, hard-to-read weird 30-year-old network stack code, panics that take down my machine instead of debuggable core dump files, etc. So I'm hoping we could get a patch review system that's more modernized. Something where anybody can easily read and quickly the patches without a bunch of email-client-specific headaches, and a sea of emails to be saved off and fed into git apply-patch, and branches ready-to-go for checkout for testing, review, and repatching if they have mistakes in them. Having the branches published centrally enables a modernized DevOps style workflow, where I can grab a new branch, run some kind of Integration Test of the feature or even just experiments with it in my own code, and go back to the central place to report how it worked, what was right and what wasn't, even better, I can send along a PR to the PR branch, with more stuff it needs before it's safe to place into master. Matthew.
[dpdk-dev] GitHub sandbox for the DPDK community
On Fri, May 01, 2015 at 03:56:32PM +, Wiles, Keith wrote: > Hi Everyone, > > I believe the DPDK community would benefit from moving to GitHub as the > primary DPDK site. http://github.com > I'm not explicitly opposed to this, but I'm having trouble matching up the technical and governance issues raised on the list as of late with the benefits you indicate github provides. Thoughts inline. > I believe the DPDK community can benefit from being at a very well know > world wide site. GitHub seems to have the most eyes of any of the open > source Git repos today and it appears they have more then twice as many > developers. GitHub has a number of features I see as some good additions to > our community using the GitHub organization account type. > Do you think that the current site dpdk.org lacks visibility? Do we have analytics on the site, or anecdotal evidence to suggest that more visiblity can be had by moving to github? It seems to me that people in search of a dataplane library google it, and dpdk is in the top 10 results, along with its wikipedia page, etc: https://www.google.com/#q=dataplane+library Not sure how using github brings on additional visibility. > The cost for an organization account is $0 as long as we do not need more > then 5 private repos. 10 private repos is $25/month and had other plans > for more. I do not see us needing more then 5 private repos today and the > only reason I can see having a private repo is to do some prep work on the > repo before making public. Every contributor would need to create a GitHub > personal account, which is at no cost unless you need more then 5 private > repos. In both accounts you can have unlimited public repos. > Given that dpdk is a public project, why would we need _any_ private repositories? They should all be public, no? > https://help.github.com/articles/where-can-i-find-open-source-projects-to-w > ork-on/ > > http://www.sitepoint.com/using-git-open-source-projects/ > > - Adding more committers can lead to a security problems for 6Wind (I > assume). In what way? Are you advocating for a single comitter here, and how does Github provide that? FWIW, I think subtree maintainers is an excellent strategy for more efficient workflow (getting patches accepted faster has been an identified problem), and allowing subtree maintainers with a comitter for each is a good way to solve that. Thats implementable with github or any other git based solution, mind you, so its neither an argument for or against github. > - 6Wind appearing to own DPDK.org is not a good message to the community. Why not? They're graciously hosting the site, and not advertizing on it (at least they shouldn't be, and I don't it egregiously displayed). Netcraft will show you lots of open source projects that host their site on a server operated by a participating company. Care has to be taken about bias, but its not uncommon. > - Not assuming 6Wind?s dpdk.org site will disappear only where the > community stores the master repos and how the community interacts with the > master. That just sounds like going back to the situation we had between dpdk.org and 01.org, where there was confusion over the canonical location to go to for dpdk information, I think we want to avoid that. > - Permission and access levels in dpdk.org is only one level and we can > benefit from having 4 levels and teams as well. Not sure what you mean by this. What access levels are you envisioning, and how is it they are not achievable with what we have today? > - The patch process today suffers from timely reviews, which will not be > fixed by moving. > - GitHub has a per pull request discussions area, which gives a clean > way to review all discussions on a specific change. > - The current patch model is clone/modify/commit/send patch set > - The model with GitHub is fork on GitHub/modify/commit/send pull > request > - The patchwork web site is reasonable, but has some draw backs in > maintaining the site. Can you ennumerate? > - GitHub manages the patches via pull requests and can be easily seen > via a web browser. > - The down side is you do have to use a web browser to do some work, but > the bulk of the everyday work would be done as it is today. > - I think we all have a web browser now :-) Yes, but as you said above, using a web browser doesn't make reviewing patches faster. In fact, I would assert that it slows the process down, as it prevents quick, easy command line access to patch review (as you have with a properly configured MUA). That seems like we're going in the opposite direction of at least one problem we would like to solve. > - GitHub has team support and gives a group better control plus > collaboration is much easier as we have a external location to work. I don't understand what you mean by an external location to work. Why is that beneficial, and why can you not just do that today if you find it beneficial. > - Most companies
[dpdk-dev] [RFC PATCH] librte_pmd_bond: add support for PCI Port Hotplug
On Fri, May 01, 2015 at 03:36:19PM +0100, Bernard Iremonger wrote:
> This patch depends on the Port Hotplug Framework.
> It implements the rte_dev_uninit_t() function for the link bonding pmd.
>
> Signed-off-by: Bernard Iremonger
> ---
> lib/librte_pmd_bond/rte_eth_bond.h | 13 -
> lib/librte_pmd_bond/rte_eth_bond_api.c | 84
>
> lib/librte_pmd_bond/rte_eth_bond_pmd.c | 23 +++-
> lib/librte_pmd_bond/rte_eth_bond_private.h |5 +-
> 4 files changed, 97 insertions(+), 28 deletions(-)
>
> diff --git a/lib/librte_pmd_bond/rte_eth_bond.h
> b/lib/librte_pmd_bond/rte_eth_bond.h
> index d688fc3..8efbf07 100644
> --- a/lib/librte_pmd_bond/rte_eth_bond.h
> +++ b/lib/librte_pmd_bond/rte_eth_bond.h
> @@ -1,7 +1,7 @@
> /*-
> * BSD LICENSE
> *
> - * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> + * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> @@ -131,6 +131,17 @@ int
> rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id);
>
> /**
> + * Free a bonded rte_eth_dev device
> + *
> + * @param name Name of the link bonding device.
> + *
> + * @return
> + * 0 on success, negative value otherwise
> + */
> +int
> +rte_eth_bond_free(const char *name);
> +
> +/**
> * Add a rte_eth_dev device as a slave to the bonded device
> *
You need to add the free routine to the version map, or shared libraries won't
work. You need to test with shared libraries as well.
> * @param bonded_port_id Port ID of bonded device.
> diff --git a/lib/librte_pmd_bond/rte_eth_bond_api.c
> b/lib/librte_pmd_bond/rte_eth_bond_api.c
> index e91a623..b91ef24 100644
> --- a/lib/librte_pmd_bond/rte_eth_bond_api.c
> +++ b/lib/librte_pmd_bond/rte_eth_bond_api.c
> @@ -44,6 +44,13 @@
>
> #define DEFAULT_POLLING_INTERVAL_10_MS (10)
>
> +static struct eth_driver rte_bond_pmd = {
> + .pci_drv = {
> + .name = "rte_bond_pmd",
> + .drv_flags = RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
> + },
> +};
> +
> int
> valid_bonded_ethdev(struct rte_eth_dev *eth_dev)
> {
> @@ -193,6 +200,7 @@ number_of_sockets(void)
> }
>
> const char *driver_name = "Link Bonding PMD";
> +static struct rte_pci_id pci_id_table = {0};
>
> int
> rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id)
> @@ -200,9 +208,8 @@ rte_eth_bond_create(const char *name, uint8_t mode,
> uint8_t socket_id)
> struct rte_pci_device *pci_dev = NULL;
> struct bond_dev_private *internals = NULL;
> struct rte_eth_dev *eth_dev = NULL;
> - struct eth_driver *eth_drv = NULL;
> struct rte_pci_driver *pci_drv = NULL;
> - struct rte_pci_id *pci_id_table = NULL;
> +
> /* now do all data allocation - for eth_dev structure, dummy pci driver
>* and internal (private) data
>*/
> @@ -224,26 +231,14 @@ rte_eth_bond_create(const char *name, uint8_t mode,
> uint8_t socket_id)
> goto err;
> }
>
> - eth_drv = rte_zmalloc_socket(name, sizeof(*eth_drv), 0, socket_id);
> - if (eth_drv == NULL) {
> - RTE_BOND_LOG(ERR, "Unable to malloc eth_drv on socket");
> - goto err;
> - }
> + pci_drv = &rte_bond_pmd.pci_drv;
>
> - pci_drv = ð_drv->pci_drv;
> + pci_id_table.device_id = PCI_ANY_ID;
> + pci_id_table.subsystem_device_id = PCI_ANY_ID;
> + pci_id_table.vendor_id = PCI_ANY_ID;
> + pci_id_table.subsystem_vendor_id = PCI_ANY_ID;
>
> - pci_id_table = rte_zmalloc_socket(name, sizeof(*pci_id_table), 0,
> socket_id);
> - if (pci_id_table == NULL) {
> - RTE_BOND_LOG(ERR, "Unable to malloc pci_id_table on socket");
> - goto err;
> - }
> - pci_id_table->device_id = PCI_ANY_ID;
> - pci_id_table->subsystem_device_id = PCI_ANY_ID;
> - pci_id_table->vendor_id = PCI_ANY_ID;
> - pci_id_table->subsystem_vendor_id = PCI_ANY_ID;
> -
> - pci_drv->id_table = pci_id_table;
> - pci_drv->drv_flags = RTE_PCI_DRV_INTR_LSC;
> + pci_drv->id_table = &pci_id_table;
>
> internals = rte_zmalloc_socket(name, sizeof(*internals), 0, socket_id);
> if (internals == NULL) {
> @@ -260,8 +255,7 @@ rte_eth_bond_create(const char *name, uint8_t mode,
> uint8_t socket_id)
>
> pci_dev->numa_node = socket_id;
> pci_drv->name = driver_name;
> -
> - eth_dev->driver = eth_drv;
> + eth_dev->driver = &rte_bond_pmd;
> eth_dev->data->dev_private = internals;
> eth_dev->data->nb_rx_queues = (uint16_t)1;
> eth_dev->data->nb_tx_queues = (uint16_t)1;
> @@ -317,13 +311,55 @@ rte_eth_bond_create(const char *name, uint8_t mode,
> uint8_t socket_id)
>
> err:
> rte_free(pci_dev);
> - rte_free(pci_id_table);
> - rte_free(eth_drv);
> rte_free(internals);
> + rte_free(eth_d
[dpdk-dev] GitHub sandbox for the DPDK community
On Fri, 1 May 2015 15:56:32 + "Wiles, Keith" wrote: > Hi Everyone, > > I believe the DPDK community would benefit from moving to GitHub as the > primary DPDK site. http://github.com > > I believe the DPDK community can benefit from being at a very well know > world wide site. GitHub seems to have the most eyes of any of the open > source Git repos today and it appears they have more then twice as many > developers. GitHub has a number of features I see as some good additions to > our community using the GitHub organization account type. > > The cost for an organization account is $0 as long as we do not need more > then 5 private repos. 10 private repos is $25/month and had other plans > for more. I do not see us needing more then 5 private repos today and the > only reason I can see having a private repo is to do some prep work on the > repo before making public. Every contributor would need to create a GitHub > personal account, which is at no cost unless you need more then 5 private > repos. In both accounts you can have unlimited public repos. > > https://help.github.com/articles/where-can-i-find-open-source-projects-to-w > ork-on/ > > http://www.sitepoint.com/using-git-open-source-projects/ > > - Adding more committers can lead to a security problems for 6Wind (I > assume). > - 6Wind appearing to own DPDK.org is not a good message to the community. > - Not assuming 6Wind?s dpdk.org site will disappear only where the > community stores the master repos and how the community interacts with the > master. > - Permission and access levels in dpdk.org is only one level and we can > benefit from having 4 levels and teams as well. > - The patch process today suffers from timely reviews, which will not be > fixed by moving. > - GitHub has a per pull request discussions area, which gives a clean > way to review all discussions on a specific change. > - The current patch model is clone/modify/commit/send patch set > - The model with GitHub is fork on GitHub/modify/commit/send pull > request > - The patchwork web site is reasonable, but has some draw backs in > maintaining the site. > - GitHub manages the patches via pull requests and can be easily seen > via a web browser. > - The down side is you do have to use a web browser to do some work, but > the bulk of the everyday work would be done as it is today. > - I think we all have a web browser now :-) > - GitHub has team support and gives a group better control plus > collaboration is much easier as we have a external location to work. > - Most companies have some pretty high security level and being to > collaborate between two or more companies is very difficult if one company > is hosting the repo behind a firewall. > - Using GitHub and teams would make collaboration a lot easier or > collaboration between two or more user accounts as well. > - GitHub has a Web Page system, which can be customized for the community > needs via a public or private repo. > - We still need a dpdk.org email list I believe as I did not find one at > GitHub. > - We can also forward GitHub emails to the list. > - I believe you can reply to an email from GitHub and the email will get > appended to the discussion thread. > In my experience the github pull model causes less review, not more. It only works if maintainers are motivated to do this as their full time job. With email, the patches are right in front of developers and easier to quote for review comments.
[dpdk-dev] GitHub sandbox for the DPDK community
On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote: > Yes, but as you said above, using a web browser doesn't make reviewing patches > faster. In fact, I would assert that it slows the process down, as it > prevents > quick, easy command line access to patch review (as you have with a properly > configured MUA). That seems like we're going in the opposite direction of at > least one problem we would like to solve. Normally I'm a big command-line supporter. However I have found reviewing patches by email for me is about the most painful workflow. The emails are pages and pages. The replies from commenters are buried in the walls of text. Replies to replies keep shifting farther off the edge of the screen. The code gets weirder and weirder to try to read. Quickly reading over the patchset by scrolling through to get the flavor of it, to see if I'm qualified to review it, and look at the parts I actually know about is much harder. I can go to one place to see every candidate patchset out there, the GH Pull Request page. Then I can just sync up the branch and test it on my own systems to see if it works, not just try to read it. Github automatically minimizes old comments that are already fixed, so they don't keep consuming space and mental bandwidth from the review. All in all, I'd be able to review more DPDK patches faster with the GH interface than having them in the mailing list. Matthew.
[dpdk-dev] NO_AUTOLIB is this variable really needed?
On Thu, Apr 30, 2015 at 05:26:57PM +0100, Wiles, Keith wrote: > > > On 4/30/15, 11:24 AM, "Richardson, Bruce" > wrote: > > >On Thu, Apr 30, 2015 at 02:55:47PM +, Wiles, Keith wrote: > >> What is the NO_AUTOLIB variable used for anyway, the doc states this: > >> > >> > >> * NO_AUTOLIBS: If set, the libraries provided by the framework will not > >>be > >> included in the LDLIBS variable automatically. > >> > >> Why was this variable created, do we have really good reason? It seems > >> like the variable removes almost all of the standard libs. > >> > >> > >> Regards, > >> ++Keith > >> > >I think that is a hang-over from the baremetal days, and can probably go > >away > >now. [It was probably used for the loader app or something] > > Do we want me to submit a patch to remove it? A new patch set :-) If it's completely unused in DPDK, it should be removed. /Bruce
[dpdk-dev] [PATCH v4 1/2] Simplify the ifdefs in rte.app.mk.
On Thu, Apr 30, 2015 at 05:33:36PM +0100, Wiles, Keith wrote: > > > On 4/30/15, 11:22 AM, "Richardson, Bruce" > wrote: > > >On Thu, Apr 30, 2015 at 02:31:13PM +, Wiles, Keith wrote: > >> > >> > >> On 4/30/15, 8:38 AM, "Olivier MATZ" wrote: > >> > >> >Hi Keith, > >> > > >> >On 04/30/2015 03:24 PM, Wiles, Keith wrote: > >> >> > >> >> > >> >> On 4/30/15, 4:45 AM, "Olivier MATZ" wrote: > >> >> > >> >>> Hi Keith, > >> >>> > >> >>> Thank you for submitting a clean-up. Please see some comments below. > >> >>> > >> >>> On 04/29/2015 05:25 PM, Keith Wiles wrote: > >> Trying to simplify the ifdefs in rte.app.mk to make the code > >> more readable and maintainable by moving LDLIBS variable to use > >> the same style as LDLIBS-y being used in the rest of the code. > >> > >> Added a new variable called EXTRA_LDLIBS to be used by example apps > >> instead of using LDLIBS directly. > >> >>> > >> >>> If I understand well, the goal of this patch is only a cleanup in > >> >>> rte.app.mk, but at the end, it changes the makefile user "API", > >> >>> which could probably be a problem for applications using the > >> >>> dpdk makefile framework. > >> >>> > >> >>> Why not just having an temporary internal variable (let's say > >> >>> _LDLIBS-y) that would allow to do the clean-up without modifying > >> >>> the user interface? > >> >>> > >> >>> Also, with your patch, the approach for EXTRA_LDLIBS would be > >> >>> different than CFLAGS or LDFLAGS: > >> >>> - CFLAGS/LDFLAGS are in Makefiles only > >> >>> - EXTRA_CFLAGS/EXTRA_LDFLAGS are prefered in command line > >> >>>to add flags to the default ones > >> >>> > >> >>> I'm not opposed to add EXTRA_LDLIBS in addition to LDLIBS, > >> >>> keeping a compatibility with existing application Makefiles. > >> >> > >> >> The docs for DPDK 28.3.6 states they can be used for both command > >>line > >> >>and > >> >> Makefile, so I think I like the current solution unless everyone > >>wants > >> >>it > >> >> as you suggested. > >> >> > >> >> > >> > http://dpdk.readthedocs.org/en/v2.0.0/prog_guide/dev_kit_build_system.h > tm > >> >>l > >> > > >> > From the link you have sent: > >> > > >> >- About CFLAGS: > >> > > >> >"28.3.4. Variables that Can be Set/Overridden in a Makefile Only > >> >[...] > >> >CFLAGS: Flags to use for C compilation. The user should use += to > >>append > >> >data in this variable." > >> > > >> >nothing in 28.3.6 > >> > > >> > > >> >- About EXTRA_CFLAGS: > >> > > >> >nothing in 28.3.4 > >> > > >> >"28.3.6. Variables that Can be Set/Overridden by the User in a Makefile > >> >or Command Line > >> >[...] > >> >EXTRA_CFLAGS: The content of this variable is appended after CFLAGS > >>when > >> >compiling." > >> > >> The point was that EXTRA_XXX can be used for command line and Makefile > >>as > >> it was pointed out in a previous email the assumption was EXTRA_XXX was > >> only for the command line. (Just to make sure we understood EXTRA_XXX > >>was > >> not just for command line options.) This was the reason I sent the link > >>an > >> to point out using EXTRA_XXX is a much cleaner method then allowing > >> someone to modify what I believe is an internal variable. > > > >Just beware that setting EXTRA_* flags on the commandline can override > >their > >values in the makefiles, and cause unexpected compilation problems. > >Therefore, > >it tends to be best to avoid using the EXTRA_* variables for variables > >essential > >to compile. For example: putting "-g -O3" in EXTRA_CFLAGS is ok, as the > >if the > >useroverrides those with something else things should still work, but > >putting > >"-I/path/to/include" would not be. > > On the command line and makefile you should be using += and not just = or > you run into this problem. Using "+=" on the commandline is not normal. It's also rather tricky to do at times, if a value is already defined, as bash shell does not add in whitespace to the existing variable appropriately. For example, I have EXTRA_CFLAGS set to '-g -Wfatal-errors' in my .bashrc so I always get debug builds that stop on first error. Building the dpdk.org as below works fine: EXTRA_CFLAGS=-g gmake == Build lib == Build lib/librte_compat ... However, using += causes very strange behaviour: $ EXTRA_CFLAGS+=-g gmake == Build lib == Build lib/librte_compat == Build lib/librte_eal == Build lib/librte_net == Build lib/librte_eal/common == Build lib/librte_eal/bsdapp == Build lib/librte_eal/bsdapp/eal == Build lib/librte_eal/bsdapp/contigmem == Build lib/librte_eal/bsdapp/nic_uio Warning: Object directory not changed from original /usr/home/bruce/dpdk.org/x86_64-native-bsdapp-clang/build/lib/librte_eal/bsdapp/nic_uio Warning: Object directory not changed from original /usr/home/bruce/dpdk.org/x86_64-native-bsdapp-clang/build/lib/librte_eal/bsdapp/contigmem CC eal.o CC eal_memory.o CC eal_hugepage_info.o CC eal_thread.o error: unknown warning option '-Wfatal-errors=g' [-Werror,-Wunknown-warning-opt
[dpdk-dev] [PATCH] Remove NO_AUTOLIBS option
NO_AUTOLIBS is not required as it was not used or defined in the config files. Signed-off-by: Keith Wiles --- mk/rte.app.mk | 5 - 1 file changed, 5 deletions(-) diff --git a/mk/rte.app.mk b/mk/rte.app.mk index b8030d2..b63e346 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -54,11 +54,8 @@ endif _LDLIBS-y += -L$(RTE_SDK_BIN)/lib # -# Include libraries depending on config if NO_AUTOLIBS is not set # Order is important: from higher level to lower level # -ifeq ($(NO_AUTOLIBS),) - _LDLIBS-y += --whole-archive _LDLIBS-$(CONFIG_RTE_BUILD_COMBINE_LIBS)+= -l$(RTE_LIBNAME) @@ -143,8 +140,6 @@ _LDLIBS-y += $(EXECENV_LDLIBS) _LDLIBS-y += --end-group _LDLIBS-y += --no-whole-archive -endif # ifeq ($(NO_AUTOLIBS),) - LDLIBS += $(_LDLIBS-y) $(EXTRA_LDLIBS) .PHONY: all -- 2.3.0
[dpdk-dev] [PATCH v6 2/2] Update Docs for new EXTRA_LDLIBS variable
Removed the LDLIBS-y reference as it is not required. Signed-off-by: Keith Wiles --- doc/build-sdk-quick.txt | 1 + doc/guides/prog_guide/build_app.rst | 2 +- doc/guides/prog_guide/dev_kit_build_system.rst | 2 ++ doc/guides/prog_guide/dev_kit_root_make_help.rst | 2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt index 041a40e..26d5442 100644 --- a/doc/build-sdk-quick.txt +++ b/doc/build-sdk-quick.txt @@ -13,6 +13,7 @@ Build variables EXTRA_CPPFLAGS preprocessor options EXTRA_CFLAGS compiler options EXTRA_LDFLAGSlinker options + EXTRA_LDLIBS linker libary options RTE_KERNELDIRlinux headers path CROSS toolchain prefix V verbose diff --git a/doc/guides/prog_guide/build_app.rst b/doc/guides/prog_guide/build_app.rst index d4a3261..983a48d 100644 --- a/doc/guides/prog_guide/build_app.rst +++ b/doc/guides/prog_guide/build_app.rst @@ -123,6 +123,6 @@ chapter for details. * CPPFLAGS: The flags to use to provide flags to the C preprocessor (only useful when assembling .S files) -* LDLIBS: A list of libraries to link with (for example, -L /path/to/libfoo - lfoo) +* LDLIBS: A list of libraries to link with (for example, -L /path/to/libfoo - lfoo) Use EXTRA_LDLIBS to add more options. * NO_AUTOLIBS: If set, the libraries provided by the framework will not be included in the LDLIBS variable automatically. diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst index cf5c96f..b8ef167 100644 --- a/doc/guides/prog_guide/dev_kit_build_system.rst +++ b/doc/guides/prog_guide/dev_kit_build_system.rst @@ -413,6 +413,8 @@ Variables that Can be Set/Overridden by the User in a Makefile or Command Line * EXTRA_LDFLAGS: The content of this variable is appended after LDFLAGS when linking. +* EXTRA_LDLIBS: The content of this variable is appended after LDLIBS when linking. + * EXTRA_ASFLAGS: The content of this variable is appended after ASFLAGS when assembling. * EXTRA_CPPFLAGS: The content of this variable is appended after CPPFLAGS when using a C preprocessor on assembly files. diff --git a/doc/guides/prog_guide/dev_kit_root_make_help.rst b/doc/guides/prog_guide/dev_kit_root_make_help.rst index 4f30192..fdc5fea 100644 --- a/doc/guides/prog_guide/dev_kit_root_make_help.rst +++ b/doc/guides/prog_guide/dev_kit_root_make_help.rst @@ -205,7 +205,7 @@ The following variables can be specified on the command line: Enable dependency debugging. This provides some useful information about why a target is built or not. -* EXTRA_CFLAGS=, EXTRA_LDFLAGS=, EXTRA_ASFLAGS=, EXTRA_CPPFLAGS= +* EXTRA_CFLAGS=, EXTRA_LDFLAGS=, EXTRA_LDLIBS=, EXTRA_ASFLAGS=, EXTRA_CPPFLAGS= Append specific compilation, link or asm flags. -- 2.3.0
[dpdk-dev] [PATCH v6 1/2] Simplify the ifdefs in rte.app.mk.
Trying to simplify the ifdefs in rte.app.mk to make the code more readable and maintainable by moving LDLIBS variable to use the same style as LDLIBS-y being used in the rest of the code. Added a new variable called EXTRA_LDLIBS to be used by example apps instead of using LDLIBS directly. The new internal variable _LDLIBS should not be used outside of the rte.app.mk file. The makefiles can still use LDLIBS, but I would suggest using EXTRA_LDLIBS instead. Signed-off-by: Keith Wiles --- examples/dpdk_qat/Makefile | 4 +- examples/vm_power_manager/Makefile | 2 +- mk/rte.app.mk | 242 + 3 files changed, 63 insertions(+), 185 deletions(-) diff --git a/examples/dpdk_qat/Makefile b/examples/dpdk_qat/Makefile index f1e06a1..90ca1d3 100644 --- a/examples/dpdk_qat/Makefile +++ b/examples/dpdk_qat/Makefile @@ -77,8 +77,8 @@ else ICP_LIBRARY_PATH = $(ICP_ROOT)/build/libicp_qa_al.a endif -LDLIBS += -L$(ICP_ROOT)/build -LDLIBS += $(ICP_LIBRARY_PATH) \ +EXTRA_LDLIBS += -L$(ICP_ROOT)/build +EXTRA_LDLIBS += $(ICP_LIBRARY_PATH) \ -lz \ -losal \ -ladf_proxy \ diff --git a/examples/vm_power_manager/Makefile b/examples/vm_power_manager/Makefile index 113dbc4..8fb78d4 100644 --- a/examples/vm_power_manager/Makefile +++ b/examples/vm_power_manager/Makefile @@ -48,7 +48,7 @@ SRCS-y += channel_monitor.c CFLAGS += -O3 -I$(RTE_SDK)/lib/librte_power/ CFLAGS += $(WERROR_FLAGS) -LDLIBS += -lvirt +EXTRA_LDLIBS += -lvirt # workaround for a gcc bug with noreturn attribute # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 62a76ae..b8030d2 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -1,7 +1,7 @@ # BSD LICENSE # -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# Copyright(c) 2014 6WIND S.A. +# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. +# Copyright(c) 2014-2015 6WIND S.A. # All rights reserved. # # Redistribution and use in source and binary forms, with or without @@ -51,7 +51,7 @@ LDSCRIPT = $(RTE_LDSCRIPT) endif # default path for libs -LDLIBS += -L$(RTE_SDK_BIN)/lib +_LDLIBS-y += -L$(RTE_SDK_BIN)/lib # # Include libraries depending on config if NO_AUTOLIBS is not set @@ -59,215 +59,93 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib # ifeq ($(NO_AUTOLIBS),) -LDLIBS += --whole-archive +_LDLIBS-y += --whole-archive -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) -LDLIBS += -l$(RTE_LIBNAME) -endif +_LDLIBS-$(CONFIG_RTE_BUILD_COMBINE_LIBS)+= -l$(RTE_LIBNAME) ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) -ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) -LDLIBS += -lrte_distributor -endif - -ifeq ($(CONFIG_RTE_LIBRTE_REORDER),y) -LDLIBS += -lrte_reorder -endif +_LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR)+= -lrte_distributor +_LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER)+= -lrte_reorder -ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) -LDLIBS += -lrte_kni -endif +_LDLIBS-$(CONFIG_RTE_LIBRTE_KNI)+= -lrte_kni +_LDLIBS-$(CONFIG_RTE_LIBRTE_IVSHMEM)+= -lrte_ivshmem endif -ifeq ($(CONFIG_RTE_LIBRTE_IVSHMEM),y) -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) -LDLIBS += -lrte_ivshmem -endif -endif +_LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE) += -lrte_pipeline +_LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE) += -lrte_table +_LDLIBS-$(CONFIG_RTE_LIBRTE_PORT) += -lrte_port +_LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer +_LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash +_LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats +_LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm +_LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl +_LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter -ifeq ($(CONFIG_RTE_LIBRTE_PIPELINE),y) -LDLIBS += -lrte_pipeline -endif +_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched +_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm +_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt -ifeq ($(CONFIG_RTE_LIBRTE_TABLE),y) -LDLIBS += -lrte_table -endif - -ifeq ($(CONFIG_RTE_LIBRTE_PORT),y) -LDLIBS += -lrte_port -endif - -ifeq ($(CONFIG_RTE_LIBRTE_TIMER),y) -LDLIBS += -lrte_timer -endif - -ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) -LDLIBS += -lrte_hash -endif - -ifeq ($(CONFIG_RTE_LIBRTE_JOBSTATS),y) -LDLIBS += -lrte_jobstats -endif - -ifeq ($(CONFIG_RTE_LIBRTE_LPM),y) -LDLIBS += -lrte_lpm -endif - -ifeq ($(CONFIG_RTE_LIBRTE_POWER),y) -LDLIBS += -lrte_power -endif - -ifeq ($(CONFIG_RTE_LIBRTE_ACL),y) -LDLIBS += -lrte_acl -endif - -ifeq ($(CONFIG_RTE_LIBRTE_METER),y) -LDLIBS += -lrte_meter -endif - -ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) -LDLIBS += -lrte_sched -LDLIBS += -lm -LDLIBS += -lrt -endif - -ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) -LDLIBS += -lrte_vhost -endif +_LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost endif # ! CONFIG_RTE_BUILD_
