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 1D2524C9F for ; Mon, 22 Oct 2018 11:04:04 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 02:04:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,411,1534834800"; d="scan'208";a="101529190" Received: from klaatz-mobl.ger.corp.intel.com (HELO [10.237.220.107]) ([10.237.220.107]) by orsmga001.jf.intel.com with ESMTP; 22 Oct 2018 02:04:01 -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: <3732754b-aaba-c339-7586-d424f94a8a73@intel.com> Date: Mon, 22 Oct 2018 10:03:58 +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: 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: Mon, 22 Oct 2018 09:04:05 -0000 Hi Mattias, Thanks for the input and clarification. I will include these changes in the v6. Regards, Kevin On 22/10/2018 08:11, Mattias Rönnblom wrote: > 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.