From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Laatz, Kevin" <kevin.laatz@intel.com>
Subject: Re: [PATCH v5 00/13] introduce telemetry library
Date: Fri, 19 Oct 2018 11:16:42 +0100
Message-ID: <f43acfa8-bbe7-3a49-1606-8b0887fd3b10@intel.com>
References: <20181011165837.81030-1-kevin.laatz@intel.com>
 <20181016155802.2067-1-kevin.laatz@intel.com>
 <9bd3f643-c587-77af-89aa-f46a1fccc70f@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: harry.van.haaren@intel.com, stephen@networkplumber.org,
 gaetan.rivet@6wind.com, shreyansh.jain@nxp.com, thomas@monjalon.net,
 bruce.richardson@intel.com
To: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= <mattias.ronnblom@ericsson.com>,
 dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
 by dpdk.org (Postfix) with ESMTP id E38291B4E7
 for <dev@dpdk.org>; Fri, 19 Oct 2018 12:16:46 +0200 (CEST)
In-Reply-To: <9bd3f643-c587-77af-89aa-f46a1fccc70f@ericsson.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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?

<Copy from the v2 feedback>
On 03/10/2018 20:06, Mattias Rönnblom wrote:
> On 2018-10-03 19:36, Kevin Laatz wrote:
>> From: Ciara Power <ciara.power@intel.com>
>> +
>> +    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