From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id CE75740021; Mon, 22 Oct 2018 09:11:21 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-173-200.mobileonline.telia.com [90.232.173.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 9F7E840005; Mon, 22 Oct 2018 09:11:19 +0200 (CEST) To: "Laatz, Kevin" , 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: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: Date: Mon, 22 Oct 2018 09:11:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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: Mon, 22 Oct 2018 07:11:23 -0000 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.