From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id E38291B4E7 for ; Fri, 19 Oct 2018 12:16:46 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 03:16:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,399,1534834800"; d="scan'208";a="98809510" Received: from klaatz-mobl.ger.corp.intel.com (HELO [10.237.220.107]) ([10.237.220.107]) by fmsmga004.fm.intel.com with ESMTP; 19 Oct 2018 03:16:44 -0700 To: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= , dev@dpdk.org Cc: harry.van.haaren@intel.com, stephen@networkplumber.org, gaetan.rivet@6wind.com, shreyansh.jain@nxp.com, thomas@monjalon.net, bruce.richardson@intel.com References: <20181011165837.81030-1-kevin.laatz@intel.com> <20181016155802.2067-1-kevin.laatz@intel.com> <9bd3f643-c587-77af-89aa-f46a1fccc70f@ericsson.com> From: "Laatz, Kevin" Message-ID: Date: Fri, 19 Oct 2018 11:16:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9bd3f643-c587-77af-89aa-f46a1fccc70f@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v5 00/13] introduce telemetry library 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: Fri, 19 Oct 2018 10:16:47 -0000 Hi Mattias, On 18/10/2018 09:07, Mattias Rönnblom wrote: > Most of the issues I pointed out in v2 of this patchset is still here. Will recheck feedback for the next version. With regards to comments on v2, 3/10, could you please help provide clarification on the below? On 03/10/2018 20:06, Mattias Rönnblom wrote: > On 2018-10-03 19:36, Kevin Laatz wrote: >> From: Ciara Power >> + >> +    if (!telemetry->request_client) { >> +        TELEMETRY_LOG_ERR("No client has been chosen to write to"); >> +        return -1; >> +    } > + >> +    if (!json_string) { >> +        TELEMETRY_LOG_ERR("Invalid JSON string!"); >> +        return -1; >> +    } >> + >> +    ret = send(telemetry->request_client->fd, >> +            json_string, strlen(json_string), 0); > > How would this code handle a partial success (as in, for example, half > of the string fits the socket buffer)? In not, maybe switching over to > a SOCK_SEQPACKET AF_UNIX socket would be the best way around it. > Is the suggestion here simply to use socket(AF_UNIX, SOCK_SEQPACKET) instead of (AF_UNIX, SOCK_STREAM) ? > >> + >> +    buffer_read = read(telemetry->accept_fd, buf, BUF_SIZE-1); > > This and the below code seem to assume that read() returns one and > only one message, but on a SOCK_STREAM, there is no such thing as a > message. It's a byte stream, and you need to provide your own framing, > or have an application protocol which allows only have one outstanding > request. If you do the latter, you still need to allow for "short" > (partial) read()s (i.e. re-read() until done). > Will the above solve this part of the problem too? Best regards, Kevin