There is a saying in software: Premature optimization is the root of all evil.
Pankaj, I said it on the mailing list, I said it today in the meeting, I am going to say one more time. There should be no conversation about offloads until there is something that can work _WITHOUT_ offloads in an efficient manner for a virtualization environment. The goalpost are: 1. Posix, Core Windows APIs or kernel APIs for a module on a reasonably well represented OS of your choice. 2. The destination of the packet is a virtualization environment. You have to bring the "data" portion of the packet into a VM. You are _NOT_ allowed to leak any headers and any metadata into the VM. Show all of us how you do it _EFFICIENTLY_ for a variable length header which is _NOT_ constant within the length of a session and for these goalposts. If you have any IPR that allows you to do so, please disclose it. Once we have figured that out, we can and will look at the "optimization" - the offloads, hardware implementation, etc. By the way - we have posted the "fixed size" code as open source so we have a verifiable benchmark versus which we can compare what you will show us. I would love to benchmark it vs what is already available. _WITHOUT_ offloads - offloads are an optimization and it must work decently without them for starters. Thanks in advance, A. On 03/03/14 16:43, Pankaj Garg wrote: Just a clarification, author’s stand is that transport provides a way to carry meta-data. Let us take NSH example, how would you carry NSH in a protocol that doesn’t have ETYPE for NextProtocol? If you think about it, then it would make sense that in one way or the other, you would need to extend the protocol to carry NSH and in turn get hardware offloads working for that protocol etc. For example, how would you carry it in VXLAN as it does not have ProtocolType field, so yes, you have to extend VXLAN, correct? You can do the following, define a generic service chaining header (which I think is anyways the right approach), then decide the mechanism to carry it in different protocols, i.e. for one class of protocols, carrying it via ETYPE may be the right approach, whereas for other protocols a different mechanism may be better. From: Surendra Kumar (smkumar) [mailto:[email protected]] Sent: Monday, March 3, 2014 10:00 PM To: Pankaj Garg; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Followup on genev metadata [Could not finish my question at the open-mic in consideration to fellow IETFrs behind me] Author's stand on the metadata from the presentation and responses: 1. Metadata is for innovating and future-proofing 2. Metadata is indeed tied to the transport 3. Metadata will be standardized as they are defined 4. If metadata needs to be used on different transports, it is up to the folks defining it to take it to each and every transport and request standardization – obviously, these needs happen for every single one of them. #4 makes absolutely no sense to me, please think about it. Why in the world does everybody have to go through the pain on every transport including those transports that are not defined yet but will be in the future. Would you rather not want these guys to standardize it once and use it in whatever transport they need to use ? Isn't that future proofing in a much better way ? Surendra. PS: BTW, this is no endorsement of the draft; rather wanted to get this straight given the discussion; I had to state It, sorry. _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
