[RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

introduce backup_classid to struct skbuff,
we can use it to backup sk_classid when net_ns switch.

Signed-off-by: Libo Chen <clbchenlibo.chen@huawei.com>
---
 include/linux/skbuff.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c5cd016..b76e871 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -492,6 +492,9 @@ struct sk_buff {
 #ifdef CONFIG_NET_CLS_ACT
 	__u16			tc_verd;	/* traffic control verdict */
 #endif
+#ifdef CONFIG_NET_CLS_CGROUP
+	__u32			backup_classid;
+#endif
 #endif

 	__u16			queue_mapping;
-- 
1.8.2.2

[RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

introduce backup_classid to struct skbuff,
we can use it to backup sk_classid when net_ns switch.

Signed-off-by: Libo Chen <clbchenlibo.chen@huawei.com>
---
 include/linux/skbuff.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c5cd016..b76e871 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -492,6 +492,9 @@ struct sk_buff {
 #ifdef CONFIG_NET_CLS_ACT
 	__u16			tc_verd;	/* traffic control verdict */
 #endif
+#ifdef CONFIG_NET_CLS_CGROUP
+	__u32			backup_classid;
+#endif
 #endif

 	__u16			queue_mapping;
-- 
1.8.2.2

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[David Miller]

From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Date: Fri, 3 Jan 2014 11:11:04 +0800

> 
> introduce backup_classid to struct skbuff,
> we can use it to backup sk_classid when net_ns switch.
> 
> Signed-off-by: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

Sorry, no new sk_buff members unless there is absolutely not other
possible implementation.

sk_buff is too big as-is.

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[David Miller]

From: Libo Chen <clbchenlibo.chen@huawei.com>
Date: Fri, 3 Jan 2014 11:11:04 +0800

> 
> introduce backup_classid to struct skbuff,
> we can use it to backup sk_classid when net_ns switch.
> 
> Signed-off-by: Libo Chen <clbchenlibo.chen@huawei.com>

Sorry, no new sk_buff members unless there is absolutely not other
possible implementation.

sk_buff is too big as-is.

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[John Fastabend]

On 01/02/2014 09:34 PM, David Miller wrote:
> From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Date: Fri, 3 Jan 2014 11:11:04 +0800
>
>>
>> introduce backup_classid to struct skbuff,
>> we can use it to backup sk_classid when net_ns switch.
>>
>> Signed-off-by: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> Sorry, no new sk_buff members unless there is absolutely not other
> possible implementation.
>
> sk_buff is too big as-is.

To get what you want fix the dev_forward_skb() call. But its
not clear to me why you would expect the sock info to be propagated
like this. It seems like an incorrect assumption or a misunderstanding
somewhere. If the virtual link was a physical link you wouldn't expect
to know anything about the senders socket.

Thanks,
John

-- 
John Fastabend         Intel Corporation

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[John Fastabend]

On 01/02/2014 09:34 PM, David Miller wrote:
> From: Libo Chen <clbchenlibo.chen@huawei.com>
> Date: Fri, 3 Jan 2014 11:11:04 +0800
>
>>
>> introduce backup_classid to struct skbuff,
>> we can use it to backup sk_classid when net_ns switch.
>>
>> Signed-off-by: Libo Chen <clbchenlibo.chen@huawei.com>
>
> Sorry, no new sk_buff members unless there is absolutely not other
> possible implementation.
>
> sk_buff is too big as-is.

To get what you want fix the dev_forward_skb() call. But its
not clear to me why you would expect the sock info to be propagated
like this. It seems like an incorrect assumption or a misunderstanding
somewhere. If the virtual link was a physical link you wouldn't expect
to know anything about the senders socket.

Thanks,
John

-- 
John Fastabend         Intel Corporation

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

On 2014/1/3 14:21, John Fastabend wrote:
> On 01/02/2014 09:34 PM, David Miller wrote:
>> From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Date: Fri, 3 Jan 2014 11:11:04 +0800
>>
>>>
>>> introduce backup_classid to struct skbuff,
>>> we can use it to backup sk_classid when net_ns switch.
>>>
>>> Signed-off-by: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>
>> Sorry, no new sk_buff members unless there is absolutely not other
>> possible implementation.
>>
>> sk_buff is too big as-is.
> 
> To get what you want fix the dev_forward_skb() call. But its
> not clear to me why you would expect the sock info to be propagated
> like this. It seems like an incorrect assumption or a misunderstanding
> somewhere. If the virtual link was a physical link you wouldn't expect
> to know anything about the senders socket.

AFAIK, once the sock is created, sock->sk_classid will be set, see sk_alloc()
so I think it is safe.

thanks,
Libo

> 
> Thanks,
> John
> 

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

On 2014/1/3 14:21, John Fastabend wrote:
> On 01/02/2014 09:34 PM, David Miller wrote:
>> From: Libo Chen <clbchenlibo.chen@huawei.com>
>> Date: Fri, 3 Jan 2014 11:11:04 +0800
>>
>>>
>>> introduce backup_classid to struct skbuff,
>>> we can use it to backup sk_classid when net_ns switch.
>>>
>>> Signed-off-by: Libo Chen <clbchenlibo.chen@huawei.com>
>>
>> Sorry, no new sk_buff members unless there is absolutely not other
>> possible implementation.
>>
>> sk_buff is too big as-is.
> 
> To get what you want fix the dev_forward_skb() call. But its
> not clear to me why you would expect the sock info to be propagated
> like this. It seems like an incorrect assumption or a misunderstanding
> somewhere. If the virtual link was a physical link you wouldn't expect
> to know anything about the senders socket.

AFAIK, once the sock is created, sock->sk_classid will be set, see sk_alloc()
so I think it is safe.

thanks,
Libo

> 
> Thanks,
> John
> 

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

On 2014/1/3 13:34, David Miller wrote:
> From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Date: Fri, 3 Jan 2014 11:11:04 +0800
> 
>>
>> introduce backup_classid to struct skbuff,
>> we can use it to backup sk_classid when net_ns switch.
>>
>> Signed-off-by: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> 
> Sorry, no new sk_buff members unless there is absolutely not other
> possible implementation.
> 

I'm kind of banging my head against the wall with this,
but can not think of a better way.

skb_shared_info is the extension for sk_buffer, how about moving into it?

any comments are appreciated!

thanks,
Libo

> sk_buff is too big as-is.
> 
> .
> 

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

On 2014/1/3 13:34, David Miller wrote:
> From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Date: Fri, 3 Jan 2014 11:11:04 +0800
> 
>>
>> introduce backup_classid to struct skbuff,
>> we can use it to backup sk_classid when net_ns switch.
>>
>> Signed-off-by: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> 
> Sorry, no new sk_buff members unless there is absolutely not other
> possible implementation.
> 

I'm kind of banging my head against the wall with this,
but can not think of a better way.

skb_shared_info is the extension for sk_buffer, how about moving into it?

any comments are appreciated!

thanks,
Libo

> sk_buff is too big as-is.
> 
> .
> 

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

On 2014/1/3 13:34, David Miller wrote:
> From: Libo Chen <clbchenlibo.chen@huawei.com>
> Date: Fri, 3 Jan 2014 11:11:04 +0800
> 
>>
>> introduce backup_classid to struct skbuff,
>> we can use it to backup sk_classid when net_ns switch.
>>
>> Signed-off-by: Libo Chen <clbchenlibo.chen@huawei.com>
> 
> Sorry, no new sk_buff members unless there is absolutely not other
> possible implementation.
> 

I'm kind of banging my head against the wall with this,
but can not think of a better way.

skb_shared_info is the extension for sk_buffer, how about moving into it?

any comments are appreciated!

thanks,
Libo

> sk_buff is too big as-is.
> 
> .
> 

Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

On 2014/1/3 13:34, David Miller wrote:
> From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Date: Fri, 3 Jan 2014 11:11:04 +0800
> 
>>
>> introduce backup_classid to struct skbuff,
>> we can use it to backup sk_classid when net_ns switch.
>>
>> Signed-off-by: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> 
> Sorry, no new sk_buff members unless there is absolutely not other
> possible implementation.
> 

I'm kind of banging my head against the wall with this,
but can not think of a better way.

skb_shared_info is the extension for sk_buffer, how about moving into it?

any comments are appreciated!

thanks,
Libo

> sk_buff is too big as-is.
> 
> .
> 

[RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff

[Libo Chen]

introduce backup_classid to struct skbuff,
we can use it to backup sk_classid when net_ns switch.

Signed-off-by: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 include/linux/skbuff.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c5cd016..b76e871 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -492,6 +492,9 @@ struct sk_buff {
 #ifdef CONFIG_NET_CLS_ACT
 	__u16			tc_verd;	/* traffic control verdict */
 #endif
+#ifdef CONFIG_NET_CLS_CGROUP
+	__u32			backup_classid;
+#endif
 #endif

 	__u16			queue_mapping;
-- 
1.8.2.2