Hi Rohith

There was one minor outstanding comment clarification.

Thanks Darrell

On 8/29/17, 4:12 AM, "Rohith Basavaraja" <[email protected]> wrote:

    
        Hi Darrell,
        
        Thanks for reviewing the document and providing the feedback.
        
        My response inline,  pl search for [Rohith]
        
        
        On 29/08/17, 1:20 AM, "Darrell Ball" <[email protected]> wrote:
        
            Hi Rohith
            
            Thanks for the improvement proposal and writeup.
            
            I wonder if it possible to divide the document by pipeline stage 
and type somehow – like receive drops, flow processing drops and
            transmit drops.
            Flow processing drops due to xlate processing error drops, explicit 
openflow drop and resource exhaustion is one division by type.
            Maybe also by subtype, such as mbuf depletion for resource 
exhaustion type, too deep recursion for xlate error…
        
        [Rohith]Not sure If I understood your comment clearly. Did you meant to 
categorize the drops as receive drops, flow processing drops and
           transmit drops? In turn for each of the category have sub 
type/gategory? In the document we intended the same, let me know if requires
        any reformatting to convey the same.


[Darrell] Receive and transmit drops is mostly fine.
                My comment was more for the flow processing drops.
                The document is already good at mentioning the different kinds 
of drops

Here is an example from the document

“
Below is a tentative list of identified silent drop scenarios. This needs to be 
completed.

●       Parsing Failures/Invalid packets.    
●       Drops due to mbuf unavailability or mbuf corruption.    
●       Errors while executing tunnel actions (like TUNNEL_POP/PUSH).
●       Errors while executing sampling actions.    
●       Recirculation error cases.    
●       Encapsulation error. 
“


However, above has at least 3 kinds of error subtypes, maybe more; something 
like:
1/ “Packet sanity errors” – eg) Parsing Failures/Invalid packets.    
2/ “Resource exhaustion errors” eg) Drops due to mbuf unavailability.    
3/ “Unsupported dp translation” eg) Recirculation error cases ?

So, what I meant was - to try to categorize more formally as such.
At the same time try to avoid "Internal DP error” since it is hard to attribute 
useful significance to it.

        
            
            It would be good if ‘Internal DP error’ had more specific errors, 
such as the above error cases.
        
        [Rohith]Ok will have subtypes for Internal DP error
            
            Would a table help here based on ‘stage’, ‘type’ and ‘subtype’ 
somehow; does not need to be as suggested above ?
        
        [Rohith]Sure,  will have table to summarize stage, type and subtype 
drops.
            
            Seems you are intending this initially for the userspace datapath ?
    [Rohith] Yes initially it’s for userspace datapath only.
    
            If you are maintaining stats on a PMD level as mentioned, did you 
consider possibly exporting this into
            pmd-stats-show (at least initially), maybe as an option, like 
verbose or extended or … ?
    
    [Rohith] Sure I consider that if that’s going to be helpful for debugging.
            
            You could separate out the implementation details to a
            separate later section; maybe some pseudocode or actual code for
            implementation discussion part.
    
    [Rohith] Ok, once the patch is ready will have separate section discussing 
the complete code flow.
    
            
            Thanks Darrell
            
            
            On 8/27/17, 11:17 PM, "[email protected] on behalf of 
Rohith Basavaraja" <[email protected] on behalf of 
[email protected]> wrote:
            
                Hi,
                
                Currently we are working on improving the packet drop 
statistics in OVS.
                
                Following link contains details of our proposal to improve 
packet drop statistics in OVS.
                
                
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1EtntZ8tPYr8lnbWyM385XMO8NIZ7v-2DRqBD1oPqLInb4_edit-3Fusp-3Dsharing&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=Hs45eNY7V06rCwaZy-m26uNMy8opKXvPKRbz2m8zRkA&s=Ys4O7MksFf7d-SP6egRvqvz--dn3-f6Sxe9MPdN5hdc&e=
 
                
                We would like to get your comments and feedback on our 
proposal. Also, welcome any suggestions
                to improve/update to our proposal.
                
                Thanks
                Rohith
                
                _______________________________________________
                dev mailing list
                [email protected]
                
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=Hs45eNY7V06rCwaZy-m26uNMy8opKXvPKRbz2m8zRkA&s=SXZvobpspWFLth9xPm591HqyseqNITCn1v5TG-jrzUM&e=
 
                
            
            
            
            
            
            
        
        
    
    

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to