[dpdk-dev] Should the other queues at same port work when one queue is full ?
I configured the 82599 ports to work in multi-queue mode and flow director to assign different TCP connections to different queues. A multi-process application receive packets from queues and each?process reads a queue. When I kill one process, the process's?queue is full, all?descriptors of the queue is used. Then I send packets to other queues, but no?packet is received by other processes from other queues. And no ierrors at the port stats.??I'm not sure it's a bug or designed that way.? I expect that when a process exits abnormally affect only part of the connections, but now all the connections are not working properly.?How can I just turn off the exception queue, so that other processes / queues work properly.
[dpdk-dev] Why nothing since 1.8.0?
On Sat, Jan 17, 2015 at 07:57:04PM +, O'driscoll, Tim wrote: > I'm going to risk the wrath of the open source purists amongst you by > top-posting. The reason is that there has been lots of email on this subject, > and I want to summarise the key issue and clearly state our position on it. > Hoperfully nobody is offended by this! > Acutally, I am a bit upset by your doing this. While top posting can be an acceptible response form, doing so in an interleaved thread gives you the opportunity to effectively rewrite the conversation on your own terms. While you might have summarized your position accurately in your mind, you've discarded all the evidence that I presented in opposition. I don't appreciate that. But we can rebuild from here, no worries. > This thread has generated lots of debate, which is good, and there are a > number of items that I believe everybody agrees on (having a MAINTAINERS > file, better tools etc.). However, the key issue that we do not agree on is > the granularity of the repositories within DPDK. > No, thats not really the crux of the debate in my mind anymore, though that is certainly part of it, as it effects the convienience of developers to contribute to the project. More to the point, the area of disagreement here is the best, most efficient way to integrate patches to various pieces of the dpdk that balances developer convienience, effiency and transparency (I've not ennumerated that last part before, as I've not thought of the right word, and that may still not be quite right, but more on it later). > The current state is: > - One master repository > - A small number of sub-repositories, each with a separate maintainer/SME, > including: i40e, fm10k, bnx2x, docs, dts. These are used to generate pull > requests to the main repo. > No, this is not the current state. The current state is: - One master repository We have lots of cloned dpdk trees on dpdk.org, but there is no path from them to the master repository. Nothing has been comitted to any of the subtrees, despite having been open for a few months now. I don't see any documentation indicating who the maintainer of each tree is, and so don't have the foggiest idea who to contact if I want to get something merged to these trees. They aren't subtrees, they're just clones of the master repository. > You're proposing the following: > - Remove the individual PMD repositories, and replace them with a single > repository containing all PMDs, plus parts of the core code that are closely > linked to the PMDs, with you as the maintainer and SMEs for each PMD. > Not necesarily me, mind you (though yes, I've volunteered). I'm happy for someone else to take on this role if they volunteer. The point is not to have a separate repo to integrate patches for any one PMD (as theres no need, and it makes development harder). I want one repository that I can use to target development against all PMDs, just like we do with net/net-next in the linux community. > As I've said before, and as Venky has also explained in private email on > this, we do not agree with this proposed change. We believe it would be a > backward step, and would have an adverse impact on DPDK. > You've asserted that several times, but not once have you provided any supporting evidence or data to back that assertion. Conversely I've provided several bits of evidence to support my assertion that using the linux workflow model would work perfectly well here and handle all our needs (which include, but are not limited to, yours). > The key issue here is that we've deliberately tried to give as much control > as possible to those who are intimately familiar with a particular PMD and > the underlying hardware. In our view, that's just common sense. What you're > proposing is to take some of that control away, and give it to someone else > (in this case you) who isn't familiar with the details. We don't agree with > that approach. > Yes, you have proposed that. The question is, why? People intimately familiar with the code should be writing and reviewing code. Why do they need the responsibility for integration as well? Thats really the question. Answer that, and perhaps we can make some process on this issue. Tell me how one of the people most familiar with a given piece of hardware and the software that drives it having the added responsibility of handling the trivial operations of SCM helps you, or anyone else? I'll point out again here that there are 6 I40e patches on the DPDK list, some as old as November 20th of last year. 4 have been ACK'd, but none have been integrated, with no additional commentary from the experts who are tasked with the patch management role. How is that efficient, transparent or condusive to development? > The arguments I've heard in favour of your proposal are summarised below. > Apologies for paraphrasing, and for any errors, but the email thread is too > big and too convoluted to address t
[dpdk-dev] [PATCH] eal / malloc : alignment parameter check failing due to changes in rte_is_power_of_2
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, January 16, 2015 5:02 PM
> To: Doherty, Declan
> Cc: dev at dpdk.org; De Lara Guarch, Pablo
> Subject: Re: [dpdk-dev] [PATCH] eal / malloc : alignment parameter check
> failing
> due to changes in rte_is_power_of_2
>
> 2015-01-16 15:10, Declan Doherty:
> > In commit 2fc8d6d the behaviour of function rte_is_power_of_2 was
> > changed to not return true for 0. memzone_reserve_aligned_thread_unsafe
> > and rte_malloc_socket both make the assumption that for align = 0
> > !rte_is_power_of_2(align) will return false. This patch adds a check
> > that align parameter is non-zero before doing the power of 2 check
> >
> > Signed-off-by: Declan Doherty
> [...]
> > - if (!rte_is_power_of_2(align)) {
> > + if (align ? !rte_is_power_of_2(align) : 0) {
> [...]
> > - if (size == 0 || !rte_is_power_of_2(align))
> > + if (size == 0 || align ? !rte_is_power_of_2(align) : 0)
>
> I don't understand why you write "align ? !rte_is_power_of_2(align) : 0"
> instead of the more readable "align && !rte_is_power_of_2(align)" ?
>
> Pablo acked it so I guess there is something obvious I'm missing.
>
> --
> Thomas
No there's nothing you're missing, this is just the way I saw the logic, if
align is none
zero, then test the power of 2 condition otherwise return 0. I have no problem
with
your suggestion in you prefer that, at the end of the day the logic test works
out equivalent.
[dpdk-dev] Why nothing since 1.8.0?
> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Sunday, January 18, 2015 6:25 PM > To: O'driscoll, Tim > Cc: Thomas Monjalon; dev at dpdk.org > Subject: Re: [dpdk-dev] Why nothing since 1.8.0? > > On Sat, Jan 17, 2015 at 07:57:04PM +, O'driscoll, Tim wrote: > > I'm going to risk the wrath of the open source purists amongst you by top- > posting. The reason is that there has been lots of email on this subject, and > I > want to summarise the key issue and clearly state our position on it. > Hoperfully nobody is offended by this! > > > Acutally, I am a bit upset by your doing this. While top posting can be an > acceptible response form, doing so in an interleaved thread gives you the > opportunity to effectively rewrite the conversation on your own terms. > While > you might have summarized your position accurately in your mind, you've > discarded all the evidence that I presented in opposition. I don't appreciate > that. But we can rebuild from here, no worries. > > > This thread has generated lots of debate, which is good, and there are a > number of items that I believe everybody agrees on (having a MAINTAINERS > file, better tools etc.). However, the key issue that we do not agree on is > the > granularity of the repositories within DPDK. > > > No, thats not really the crux of the debate in my mind anymore, though that > is > certainly part of it, as it effects the convienience of developers to > contribute > to the project. More to the point, the area of disagreement here is the best, > most efficient way to integrate patches to various pieces of the dpdk that > balances developer convienience, effiency and transparency (I've not > ennumerated > that last part before, as I've not thought of the right word, and that may > still > not be quite right, but more on it later). > > > The current state is: > > - One master repository > > - A small number of sub-repositories, each with a separate > maintainer/SME, including: i40e, fm10k, bnx2x, docs, dts. These are used to > generate pull requests to the main repo. > > > No, this is not the current state. The current state is: > - One master repository We have a repository for docs, with a separate maintainer that was used to generate pull requests for 1.8. From our perspective that worked well. For i40e, 1.8 development was done in the main repository, and we agreed to transition to a separate repo for 2.0. 2.0 development is currently in progress. We haven't upstreamed anything for fm10k yet, but that will be done in its own repo from the start, for the 2.0 release. > We have lots of cloned dpdk trees on dpdk.org, but there is no path from > them to > the master repository. Nothing has been comitted to any of the subtrees, > despite having been open for a few months now. The plan is to use the i40e and fm10k repos for 2.0 development, which is in progress. > I don't see any > documentation > indicating who the maintainer of each tree is, and so don't have the foggiest > idea who to contact if I want to get something merged to these trees. They > aren't subtrees, they're just clones of the master repository. A MAINTAINERS file to clarify responsibilities is a good idea. > > You're proposing the following: > > - Remove the individual PMD repositories, and replace them with a single > repository containing all PMDs, plus parts of the core code that are closely > linked to the PMDs, with you as the maintainer and SMEs for each PMD. > > > Not necesarily me, mind you (though yes, I've volunteered). I'm happy for > someone else to take on this role if they volunteer. The point is not to have > a > separate repo to integrate patches for any one PMD (as theres no need, and > it > makes development harder). I want one repository that I can use to target > development against all PMDs, just like we do with net/net-next in the linux > community. > > > As I've said before, and as Venky has also explained in private email on > > this, > we do not agree with this proposed change. We believe it would be a > backward step, and would have an adverse impact on DPDK. > > > You've asserted that several times, but not once have you provided any > supporting evidence or data to back that assertion. Conversely I've provided > several bits of evidence to support my assertion that using the linux > workflow > model would work perfectly well here and handle all our needs (which > include, > but are not limited to, yours). The reason is to give as much control as possible to the people most familiar with the PMD code and the corresponding NIC hardware. > > The key issue here is that we've deliberately tried to give as much control > as possible to those who are intimately familiar with a particular PMD and the > underlying hardware. In our view, that's just common sense. What you're > proposing is to take some of that control away, and give it to someone else > (in this case you) who isn't familiar with the
[dpdk-dev] [PATCH v5 0/6] Enable VF RSS for Niantic
2015-01-08 11:56, Vlad Zolotarov: > I've acked PATCH1 and PATCH2 already before and since there are no > changes in them, pls., consider them ACKed... ;) Thank you for the great review. Note to everybody reading that: Vlad approved the 2 first patches of the serie at v4 stage. So it would be clearer (and easier when applying patches) to set the ack or reviewed-by line in the next versions if there are no changes (or minor) to these patches. It's a good habit which is not well spread in DPDK community. Thanks -- Thomas
[dpdk-dev] [PATCH v6 4/6] ether: Check VMDq RSS mode
2015-01-12 13:59, Ouyang Changchun: > Check mq mode for VMDq RSS, handle it correctly instead of returning an error; > Also remove the limitation of per pool queue number has max value of 1, > because > the per pool queue number could be 2 or 4 if it is VMDq RSS mode; > > The number of rxq specified in config will determine the mq mode for VMDq RSS. > > Signed-off-by: Changchun Ouyang I feel that most of this code is Intel-specific and should go in ixgbe or other PMDs if needed. OK to apply this patch which improves the current codebase, but please, start thinking how RSS/VMDQ/DCB features are generic. -- Thomas
[dpdk-dev] [PATCH v6 0/6] Enable VF RSS for Niantic
> This patch enables VF RSS for Niantic, which allow each VF having at most 4
> queues.
> The actual queue number per VF depends on the total number of pool, which is
> determined by the max number of VF at PF initialization stage and the number
> of
> queue specified in config:
> 1) If the max number of VF is in the range from 1 to 32, and the number of
> rxq is 4
> ('--rxq 4' in testpmd), then there is totally 32 pools(ETH_32_POOLS), and
> each VF
> have 4 queues;
>
> 2)If the max number of VF is in the range from 33 to 64, and the number of
> rxq is 2
> ('--rxq 2' in testpmd), then there is totally 64 pools(ETH_64_POOLS), and
> each VF
> have 2 queues;
>
> On host, to enable VF RSS functionality, rx mq mode should be set as
> ETH_MQ_RX_VMDQ_RSS
> or ETH_MQ_RX_RSS mode, and SRIOV mode should be activated(max_vfs >= 1).
> It also needs config VF RSS information like hash function, RSS key, RSS key
> length.
>
> The limitation for Niantic VF RSS is:
> the hash and key are shared among PF and all VF, the RETA table with 128
> entries are
> also shared among PF and all VF. So it could not to provide a method to query
> the hash
> and reta content per VF on guest, while, if possible, please query them on
> host(PF) for
> the shared RETA information.
This kind of information should go in a documentation.
I think we should start new documentation for PMDs.
What about a doc/drivers/ directory ?
> changes in v6:
> - refine codes and update message according to comments;
>
> changes in v5:
> - Fix minor issue and some comments;
>
> changes in v4:
> - Extract a function to remove embeded switch-case statement;
> - Check whether RX queue number is a valid one, otherwise return error;
> - Update the description a bit;
>
> changes in v3:
> - More cleanup;
>
> changes in v2:
> - Update the description;
> - Use receiving queue number('--rxq ') specified in config to
> determine the
> number of pool and the number of queue per VF;
>
> changes in v1:
> - Config VF RSS;
>
> Changchun Ouyang (6):
> ixgbe: Code cleanup
> ixgbe: Negotiate VF API version
> ixgbe: Get VF queue number
> ether: Check VMDq RSS mode
> ixgbe: Config VF RSS
> testpmd: Set Rx VMDq RSS mode
Deeply reviewed by Vlad Zolotarov. Thanks!
Applied
Thanks to both of you
--
Thomas
