Re: [dpdk-dev] [PATCH v5 00/13] introduce telemetry library

["Mattias Rönnblom" <mattias.ronnblom@ericsson.com>]

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 <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) ?

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.