Re: [openstack-dev] [nova][pci]PCI SR-IOV use cases initial doc
Hi John, Sorry for the late response. I was completely tied up with something. I agree with your comments on the use cases. Once there are the use cases, given all the Config vs API debates, I would look at the pure data flow, in a Config/API agnostic way. Agreeing the info needed from the user, then in the VIF driver, then in between, etc. We should be able to agree on that, before returning to the host aggregates API vs something new API vs more config debate. I have seen your comments with Irenab’s nova-spec. I will try to reply as well. And let’s go over the use cases outlined in that spec in tomorrow’s IRC meeting. Thanks, Robert On 4/10/14, 4:40 AM, John Garbutt j...@johngarbutt.com wrote: Apologies, that came out all wrong... On 10 April 2014 09:28, John Garbutt j...@johngarbutt.com wrote: I think writing this up as a nova-spec is going to make this process much easier: https://wiki.openstack.org/wiki/Blueprints#Nova It will save you having to re-write your document once you want to submit a blueprint, and we can all see each others comments in gerrit, and more clearly see how things change and evolve. The way the template in nova-spec works, it should also help you with structuring your argument. Thats just want I would find easier, its just a suggestion. Please don't design assuming a single vendor solution, that is sure to get rejected (at least my me) at the blueprint review stage. You might want a different vendor in each AZ to isolate you from failures due to vendor bugs, if you are digging for a use case. I guess thats a tenant use case, I got confused reading through those. I still can't see a clear description of the tenant use cases, I still think thats the key to getting agreement here, and getting useful feedback at the summit. Not sure I understand the tables, they seem a bit confusing/distracting. Sorry, forgot to mention, you are making good progress here. But, given the loop we are going around here, I think agreeing the ideal use cases, then looking at the detail, and looping back to see if everything works is probably the right approach. Other ideas welcome! Once there are the use cases, given all the Config vs API debates, I would look at the pure data flow, in a Config/API agnostic way. Agreeing the info needed from the user, then in the VIF driver, then in between, etc. We should be able to agree on that, before returning to the host aggregates API vs something new API vs more config debate. Right it doesn't seem to be clear what is required, so its hard to know what the best approach is, compared to other features we already have in Nova. At the moment I am struggling to see the whole picture, getting the general idea clear before the summit would be awesome, so we can discuss how to stage the implementation, deal with backwards compatibility, etc. Thanks, John On 10 April 2014 09:14, yongli he yongli...@intel.com wrote: 于 2014年04月10日 15:59, Irena Berezovsky 写道: Hi Robert, Thanks a lot the inputs you posted in the doc. I have raised there few questions and added use case for High Availability. Another concern I have is regarding the assumption that there is no case to mix different vendor cards in the setup. I think that mixing Cisco and Intel or Mellanox cards does not make sense, but Intel and Mellanox cards can coexist. At least for my understanding, but I may be wrong, both Intel and Mellanox take HW VEB (HW embedded switch) approach. 1. open to mail list. 2. admin/usr won't mixing Intel/Cisco/Mellanox card, does not mean we should disable it, or don't give a chance. 3. i raise couple of question and questioning the aggregate solution. see inline comments. https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGL BrKslmw/edit Yongli He Thanks, Irena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, April 09, 2014 11:11 PM To: Irena Berezovsky; Sandhya Dasu (sadasu); Robert Kukura; He, Yongli (yongli...@intel.com); Itzik Brown; beag...@redhat.com Subject: Re: PCI SR-IOV use cases initial doc Hi, I updated the doc with some of my thoughts. Thanks, Robert On 3/24/14, 8:41 AM, Irena Berezovsky ire...@mellanox.com wrote: Hi, I have created the initial doc to capture PCI SR-IOV networking use cases: https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGL BrKslmw/edit I have updated the agenda for tomorrow meeting to discuss the use cases. Please comment and update BR, Irena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][pci]PCI SR-IOV use cases initial doc
? 2014?04?10? 15:59, Irena Berezovsky ??: Hi Robert, Thanks a lot the inputs you posted in the doc. I have raised there few questions and added use case for High Availability. Another concern I have is regarding the assumption that there is no case to mix different vendor cards in the setup. I think that mixing Cisco and Intel or Mellanox cards does not make sense, but Intel and Mellanox cards can coexist. At least for my understanding, but I may be wrong, both Intel and Mellanox take HW VEB (HW embedded switch) approach. 1. open to mail list. 2. admin/usr won't mixing Intel/Cisco/Mellanox card, does not mean we should disable it, or don't give a chance. 3. i raise couple of question and questioning the aggregate solution. see inline comments. https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit Yongli He Thanks, Irena *From:*Robert Li (baoli) [mailto:ba...@cisco.com] *Sent:* Wednesday, April 09, 2014 11:11 PM *To:* Irena Berezovsky; Sandhya Dasu (sadasu); Robert Kukura; He, Yongli (yongli...@intel.com); Itzik Brown; beag...@redhat.com *Subject:* Re: PCI SR-IOV use cases initial doc Hi, I updated the doc with some of my thoughts. Thanks, Robert On 3/24/14, 8:41 AM, Irena Berezovsky ire...@mellanox.com mailto:ire...@mellanox.com wrote: Hi, I have created the initial doc to capture PCI SR-IOV networking use cases: https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit I have updated the agenda for tomorrow meeting to discuss the use cases. Please comment and update BR, Irena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][pci]PCI SR-IOV use cases initial doc
I think writing this up as a nova-spec is going to make this process much easier: https://wiki.openstack.org/wiki/Blueprints#Nova It will save you having to re-write your document once you want to submit a blueprint, and we can all see each others comments in gerrit, and more clearly see how things change and evolve. The way the template in nova-spec works, it should aslo help you with structuring your argument. Please don't design assuming a single vendor solution, that is sure to get rejected (at least my me) at the blueprint review stage. You might want a different vendor in each AZ to isolate you from failures due to vendor bugs, if you are digging for a use case. I still can't see a clear description of the tenant use cases, I still think thats the key to getting agreement here, and getting useful feedback at the summit. Not sure I understand the tables, they seem a bit confusing/distracting. John On 10 April 2014 09:14, yongli he yongli...@intel.com wrote: 于 2014年04月10日 15:59, Irena Berezovsky 写道: Hi Robert, Thanks a lot the inputs you posted in the doc. I have raised there few questions and added use case for High Availability. Another concern I have is regarding the assumption that there is no case to mix different vendor cards in the setup. I think that mixing Cisco and Intel or Mellanox cards does not make sense, but Intel and Mellanox cards can coexist. At least for my understanding, but I may be wrong, both Intel and Mellanox take HW VEB (HW embedded switch) approach. 1. open to mail list. 2. admin/usr won't mixing Intel/Cisco/Mellanox card, does not mean we should disable it, or don't give a chance. 3. i raise couple of question and questioning the aggregate solution. see inline comments. https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit Yongli He Thanks, Irena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, April 09, 2014 11:11 PM To: Irena Berezovsky; Sandhya Dasu (sadasu); Robert Kukura; He, Yongli (yongli...@intel.com); Itzik Brown; beag...@redhat.com Subject: Re: PCI SR-IOV use cases initial doc Hi, I updated the doc with some of my thoughts. Thanks, Robert On 3/24/14, 8:41 AM, Irena Berezovsky ire...@mellanox.com wrote: Hi, I have created the initial doc to capture PCI SR-IOV networking use cases: https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit I have updated the agenda for tomorrow meeting to discuss the use cases. Please comment and update BR, Irena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][pci]PCI SR-IOV use cases initial doc
于 2014年04月10日 16:28, John Garbutt 写道: I think writing this up as a nova-spec is going to make this process much easier: https://wiki.openstack.org/wiki/Blueprints#Nova It will save you having to re-write your document once you want to submit a blueprint, and we can all see each others comments in gerrit, and more clearly see how things change and evolve. The way the template in nova-spec works, it should aslo help you with structuring your argument. yeah, this worthy to do now, i begin to format my own bp to a spec. Please don't design assuming a single vendor solution, that is sure to agree. get rejected (at least my me) at the blueprint review stage. You might want a different vendor in each AZ to isolate you from failures due to vendor bugs, if you are digging for a use case. I still can't see a clear description of the tenant use cases, I still think thats the key to getting agreement here, and getting useful feedback at the summit. Not sure I understand the tables, they seem a bit confusing/distracting. yeah, maybe because it's hard to description the use case flow without bothering a reference design . John On 10 April 2014 09:14, yongli he yongli...@intel.com wrote: 于 2014年04月10日 15:59, Irena Berezovsky 写道: Hi Robert, Thanks a lot the inputs you posted in the doc. I have raised there few questions and added use case for High Availability. Another concern I have is regarding the assumption that there is no case to mix different vendor cards in the setup. I think that mixing Cisco and Intel or Mellanox cards does not make sense, but Intel and Mellanox cards can coexist. At least for my understanding, but I may be wrong, both Intel and Mellanox take HW VEB (HW embedded switch) approach. 1. open to mail list. 2. admin/usr won't mixing Intel/Cisco/Mellanox card, does not mean we should disable it, or don't give a chance. 3. i raise couple of question and questioning the aggregate solution. see inline comments. https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit Yongli He Thanks, Irena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, April 09, 2014 11:11 PM To: Irena Berezovsky; Sandhya Dasu (sadasu); Robert Kukura; He, Yongli (yongli...@intel.com); Itzik Brown; beag...@redhat.com Subject: Re: PCI SR-IOV use cases initial doc Hi, I updated the doc with some of my thoughts. Thanks, Robert On 3/24/14, 8:41 AM, Irena Berezovsky ire...@mellanox.com wrote: Hi, I have created the initial doc to capture PCI SR-IOV networking use cases: https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit I have updated the agenda for tomorrow meeting to discuss the use cases. Please comment and update BR, Irena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][pci]PCI SR-IOV use cases initial doc
Apologies, that came out all wrong... On 10 April 2014 09:28, John Garbutt j...@johngarbutt.com wrote: I think writing this up as a nova-spec is going to make this process much easier: https://wiki.openstack.org/wiki/Blueprints#Nova It will save you having to re-write your document once you want to submit a blueprint, and we can all see each others comments in gerrit, and more clearly see how things change and evolve. The way the template in nova-spec works, it should also help you with structuring your argument. Thats just want I would find easier, its just a suggestion. Please don't design assuming a single vendor solution, that is sure to get rejected (at least my me) at the blueprint review stage. You might want a different vendor in each AZ to isolate you from failures due to vendor bugs, if you are digging for a use case. I guess thats a tenant use case, I got confused reading through those. I still can't see a clear description of the tenant use cases, I still think thats the key to getting agreement here, and getting useful feedback at the summit. Not sure I understand the tables, they seem a bit confusing/distracting. Sorry, forgot to mention, you are making good progress here. But, given the loop we are going around here, I think agreeing the ideal use cases, then looking at the detail, and looping back to see if everything works is probably the right approach. Other ideas welcome! Once there are the use cases, given all the Config vs API debates, I would look at the pure data flow, in a Config/API agnostic way. Agreeing the info needed from the user, then in the VIF driver, then in between, etc. We should be able to agree on that, before returning to the host aggregates API vs something new API vs more config debate. Right it doesn't seem to be clear what is required, so its hard to know what the best approach is, compared to other features we already have in Nova. At the moment I am struggling to see the whole picture, getting the general idea clear before the summit would be awesome, so we can discuss how to stage the implementation, deal with backwards compatibility, etc. Thanks, John On 10 April 2014 09:14, yongli he yongli...@intel.com wrote: 于 2014年04月10日 15:59, Irena Berezovsky 写道: Hi Robert, Thanks a lot the inputs you posted in the doc. I have raised there few questions and added use case for High Availability. Another concern I have is regarding the assumption that there is no case to mix different vendor cards in the setup. I think that mixing Cisco and Intel or Mellanox cards does not make sense, but Intel and Mellanox cards can coexist. At least for my understanding, but I may be wrong, both Intel and Mellanox take HW VEB (HW embedded switch) approach. 1. open to mail list. 2. admin/usr won't mixing Intel/Cisco/Mellanox card, does not mean we should disable it, or don't give a chance. 3. i raise couple of question and questioning the aggregate solution. see inline comments. https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit Yongli He Thanks, Irena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, April 09, 2014 11:11 PM To: Irena Berezovsky; Sandhya Dasu (sadasu); Robert Kukura; He, Yongli (yongli...@intel.com); Itzik Brown; beag...@redhat.com Subject: Re: PCI SR-IOV use cases initial doc Hi, I updated the doc with some of my thoughts. Thanks, Robert On 3/24/14, 8:41 AM, Irena Berezovsky ire...@mellanox.com wrote: Hi, I have created the initial doc to capture PCI SR-IOV networking use cases: https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit I have updated the agenda for tomorrow meeting to discuss the use cases. Please comment and update BR, Irena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][pci]PCI SR-IOV use cases initial doc
于 2014年04月10日 16:40, John Garbutt 写道: Apologies, that came out all wrong... On 10 April 2014 09:28, John Garbutt j...@johngarbutt.com wrote: I think writing this up as a nova-spec is going to make this process much easier: https://wiki.openstack.org/wiki/Blueprints#Nova It will save you having to re-write your document once you want to submit a blueprint, and we can all see each others comments in gerrit, and more clearly see how things change and evolve. The way the template in nova-spec works, it should also help you with structuring your argument. Thats just want I would find easier, its just a suggestion. Please don't design assuming a single vendor solution, that is sure to get rejected (at least my me) at the blueprint review stage. You might want a different vendor in each AZ to isolate you from failures due to vendor bugs, if you are digging for a use case. I guess thats a tenant use case, I got confused reading through those. I still can't see a clear description of the tenant use cases, I still think thats the key to getting agreement here, and getting useful feedback at the summit. Not sure I understand the tables, they seem a bit confusing/distracting. Sorry, forgot to mention, you are making good progress here. But, given the loop we are going around here, I think agreeing the ideal use cases, then looking at the detail, and looping back to see if everything works is probably the right approach. Other ideas welcome! Once there are the use cases, given all the Config vs API debates, I about use cases, i might have different picture in my head , i.e how do you think this: tenant user want to pick up a PCI acceleration card with MD5 and RC6 encryption/hash support. 1. is this the use case you are look for? 2. what other information should be add to this use-case? and any other suggestion? Yongli he would look at the pure data flow, in a Config/API agnostic way. Agreeing the info needed from the user, then in the VIF driver, then in between, etc. We should be able to agree on that, before returning to the host aggregates API vs something new API vs more config debate. Right it doesn't seem to be clear what is required, so its hard to know what the best approach is, compared to other features we already have in Nova. At the moment I am struggling to see the whole picture, getting the general idea clear before the summit would be awesome, so we can discuss how to stage the implementation, deal with backwards compatibility, etc. Thanks, John On 10 April 2014 09:14, yongli he yongli...@intel.com wrote: 于 2014年04月10日 15:59, Irena Berezovsky 写道: Hi Robert, Thanks a lot the inputs you posted in the doc. I have raised there few questions and added use case for High Availability. Another concern I have is regarding the assumption that there is no case to mix different vendor cards in the setup. I think that mixing Cisco and Intel or Mellanox cards does not make sense, but Intel and Mellanox cards can coexist. At least for my understanding, but I may be wrong, both Intel and Mellanox take HW VEB (HW embedded switch) approach. 1. open to mail list. 2. admin/usr won't mixing Intel/Cisco/Mellanox card, does not mean we should disable it, or don't give a chance. 3. i raise couple of question and questioning the aggregate solution. see inline comments. https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit Yongli He Thanks, Irena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, April 09, 2014 11:11 PM To: Irena Berezovsky; Sandhya Dasu (sadasu); Robert Kukura; He, Yongli (yongli...@intel.com); Itzik Brown; beag...@redhat.com Subject: Re: PCI SR-IOV use cases initial doc Hi, I updated the doc with some of my thoughts. Thanks, Robert On 3/24/14, 8:41 AM, Irena Berezovsky ire...@mellanox.com wrote: Hi, I have created the initial doc to capture PCI SR-IOV networking use cases: https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit I have updated the agenda for tomorrow meeting to discuss the use cases. Please comment and update BR, Irena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
