From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id AB64D11A4 for ; Mon, 10 Sep 2018 10:34:17 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 76CBC780069; Mon, 10 Sep 2018 08:34:16 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Sep 2018 01:34:12 -0700 To: David Marchand , Olivier Matz CC: , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" References: <20180910054547.18494-1-david.marchand@6wind.com> <20180910054547.18494-3-david.marchand@6wind.com> <86b2ae63-f193-03ce-457d-387b785fb884@solarflare.com> From: Andrew Rybchenko Message-ID: <8d525334-f770-7627-4023-c61aa92f4655@solarflare.com> Date: Mon, 10 Sep 2018 11:33:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ocex03.SolarFlarecom.com (10.20.40.36) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24084.005 X-TM-AS-Result: No-13.061200-4.000000-10 X-TMASE-MatchedRID: eVEkOcJu0F6hGvK1s4lxDSa1MaKuob8PC/ExpXrHizxBR/SqOphhnCt9 xiAirjf/GEqTc9Sy9aYB/7KOz8XhVWTCzF7UO28xHcQQBuf4ZFuZf5btvM85AWq//5Ao1w8uxsG X6Z1g80MurP/Wr9G5LXNDvX+VVWbWkbjrxLvJ6LAj2wh8RSKcGEoPOT/GTMuGTUobVis5Bb8Ddb qf2nbl9KfdkqjWLNAxXkQj/e2dwcNzfeCSt9MtiGg4D2QV/2zL6r3HCixfuKcML9Wb3Qh/hVTNq f3EQ8oxYnP+cq2mFg5XmxqYx7OZlsZXUijhl2l8GQlUVP2iPcxMFWXO7lee9UIjuk0uJKN9xTPN 0i7ijGH3aCtTBCBhl3k48PxckV+kTX7PJ/OU3vKDGx/OQ1GV8rHlqZYrZqdItVX2a1/ZsVj6hPq LSGzcMzA0TMGnTPXSFqvFeMJpPKJO+iEfQ+lnzXTvAsqVXcjW27NiIUDisv+NV1Xub1b2F1XIuZ oSesTv1H0OjUNJcUU= X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.061200-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24084.005 X-MDID: 1536568457-e3lvr6qUR5gx Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 2/3] mbuf: add a non fatal sanity check helper X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 08:34:17 -0000 On 09/10/2018 11:24 AM, David Marchand wrote: > On Mon, Sep 10, 2018 at 10:12 AM, Andrew Rybchenko > wrote: >> +/** >> + * Sanity checks on a mbuf. >> + * >> + * Almost like rte_mbuf_sanity_check(), but this function gives the reason >> + * if corruption is detected rather than panic. >> + * >> + * @param m >> + * The mbuf to be checked. >> + * @param is_header >> + * True if the mbuf is a packet header, false if it is a sub-segment >> + * of a packet (in this case, some fields like nb_segs are not checked) >> + * @param reason >> + * A reference to a string pointer where to store the reason why a mbuf >> is >> + * considered invalid. >> + * @return >> + * - 0 if no issue has been found, reason is left untouched. >> + * - -1 if a problem is detected, reason then points to a string >> describing >> + * the reason why the mbuf is deemed invalid. >> + */ >> +__rte_experimental >> +int rte_mbuf_check(const struct rte_mbuf *m, int is_header, >> + const char **reason); >> + >> >> >> May be it would be better to return reason as return value and if it is NULL >> everything is OK? > This was what I had done with my first attempt. > But given the name "rte_mbuf_check", having a int (used as a bool) > returned makes sense to me. Yes, good point. > So no strong opinion here. Me too.