[CRIU] [PATCH v2 06/15] unix: Add sender_ino of packets and socket

[Kirill Tkhai]

On 01.06.2016 17:39, Pavel Emelyanov wrote:
> On 06/01/2016 01:51 PM, Kirill Tkhai wrote:
>> On 01.06.2016 13:45, Pavel Emelyanov wrote:
>>> On 05/31/2016 04:03 PM, Kirill Tkhai wrote:
>>>>
>>>>
>>>> On 31.05.2016 14:02, Pavel Emelyanov wrote:
>>>>> On 05/30/2016 03:30 PM, Kirill Tkhai wrote:
>>>>>>
>>>>>>
>>>>>> On 30.05.2016 14:40, Pavel Emelyanov wrote:
>>>>>>> On 05/27/2016 04:06 PM, Kirill Tkhai wrote:
>>>>>>>> Add optional field "sender_ino" to packet and socket proto.
>>>>>>>>
>>>>>>>> Signed-off-by: Kirill Tkhai <ktkhai at virtuozzo.com>
>>>>>>>> ---
>>>>>>>>  images/sk-packet.proto |    1 +
>>>>>>>>  images/sk-unix.proto   |    2 ++
>>>>>>>>  2 files changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/images/sk-packet.proto b/images/sk-packet.proto
>>>>>>>> index 10ef5c9..2e1c8b3 100644
>>>>>>>> --- a/images/sk-packet.proto
>>>>>>>> +++ b/images/sk-packet.proto
>>>>>>>> @@ -1,4 +1,5 @@
>>>>>>>>  message sk_packet_entry {
>>>>>>>>  	required uint32		id_for		= 1;
>>>>>>>>  	required uint32		length		= 2;
>>>>>>>> +	optional uint32		sender_ino	= 3;
>>>>>>>
>>>>>>> This is understood.
>>>>>>>
>>>>>>>>  }
>>>>>>>> diff --git a/images/sk-unix.proto b/images/sk-unix.proto
>>>>>>>> index aa2bcf7..7b71ebf 100644
>>>>>>>> --- a/images/sk-unix.proto
>>>>>>>> +++ b/images/sk-unix.proto
>>>>>>>> @@ -45,4 +45,6 @@ message unix_sk_entry {
>>>>>>>>  	 * Relative socket name may have prefix.
>>>>>>>>  	 */
>>>>>>>>  	optional string			name_dir	= 14;
>>>>>>>> +
>>>>>>>> +	optional uint32			sender_ino	= 15;
>>>>>>>
>>>>>>> Why do you need this new number on socket entry?
>>>>>>
>>>>>> This allows to understand that a DGRAM socket is not a promiscuous.
>>>>>> If so, we may set a sender as our queuer (see sk_queuer()).
>>>>>>
>>>>>> Otherwise, we would have to do additional work on restore. We would
>>>>>> have to scan skb queue to understand if it's promiscuous.
>>>>>>
>>>>>> Using unix_sk_entry::sender_ino, we easily mark the most sockets as
>>>>>> "having queuer", and skip them on "resolve senders" stage.
>>>>>> See resolve_unix_peers() changes.
>>>>>
>>>>> OK. From my perspective you don't need this in image. During resolve_unix_peers()
>>>>> we scan all the sockets, you can add analysis of the packets and find out
>>>>> whether the socket is no-queuer or not.
>>>>
>>>> I think this trick may speed-up restore in some way. If you are worrying about
>>>> using of space for that, I can add USK_HAS_SENDER flag instead. Is it OK for you?
>>>
>>> No, please. The information in sk-packet.img is enough to decide what
>>> kind of sender restore we have. We pull in this image into memory anyway.
>>
>> But if we decide this on restore, it will require [nr sockers] x [nr packers] comparations.
> 
> Don't we do the same on dump side? You have sockets and packets in them,
> you have to find out whether each socket has zero, one or many queuers.
> What's the difference when doing it?

On dump we receive socket's packets and simply compare cur_pkt_ino != prev_pkt_ino.
No iteration is there. So the difference presents.

Anyway, if you think it's not big time wasted here, I do a version without precalculated sender.