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

[Kirill Tkhai]

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.