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

[Pavel Emelyanov]

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?