From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Subject: Re: [PATCH v5 00/13] introduce telemetry library Date: Mon, 22 Oct 2018 09:11:18 +0200 Message-ID: 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: "Laatz, Kevin" , dev@dpdk.org Return-path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 38C1C4CA7 for ; Mon, 22 Oct 2018 09:11:22 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E34554002C for ; Mon, 22 Oct 2018 09:11:21 +0200 (CEST) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 2018-10-19 12:16, Laatz, Kevin wrote: > 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) ? That would be the most straight-forward to the problem, I think. Linux' SOCK_SEQPACKET implementation has problems with really large messages (since a per-message linear buffer is allocated), but I'm guessing these messages are not in the hundreds-of-kb range. >> >>> + >>> +    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? > Yes. The kernel will delivered the application (at most) one message, in its entirety.