* [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff
@ 2014-01-03 3:11 Libo Chen
2014-01-03 5:34 ` David Miller
0 siblings, 1 reply; 5+ messages in thread
From: Libo Chen @ 2014-01-03 3:11 UTC (permalink / raw)
To: David Miller
Cc: edumazet, jasowang, horms, Serge Hallyn, netdev, cgroups,
containers, kaber, xemul, ebiederm, LKML, jhs, Li Zefan
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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff
2014-01-03 3:11 [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff Libo Chen
@ 2014-01-03 5:34 ` David Miller
2014-01-03 6:21 ` John Fastabend
2014-01-07 12:54 ` Libo Chen
0 siblings, 2 replies; 5+ messages in thread
From: David Miller @ 2014-01-03 5:34 UTC (permalink / raw)
To: clbchenlibo.chen
Cc: edumazet, jasowang, horms, serge.hallyn, netdev, cgroups,
containers, kaber, xemul, ebiederm, linux-kernel, jhs, lizefan
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff
2014-01-03 5:34 ` David Miller
@ 2014-01-03 6:21 ` John Fastabend
2014-01-06 8:16 ` Libo Chen
2014-01-07 12:54 ` Libo Chen
1 sibling, 1 reply; 5+ messages in thread
From: John Fastabend @ 2014-01-03 6:21 UTC (permalink / raw)
To: clbchenlibo.chen
Cc: David Miller, edumazet, jasowang, horms, serge.hallyn, netdev,
cgroups, containers, kaber, xemul, ebiederm, linux-kernel, jhs,
lizefan
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff
2014-01-03 6:21 ` John Fastabend
@ 2014-01-06 8:16 ` Libo Chen
0 siblings, 0 replies; 5+ messages in thread
From: Libo Chen @ 2014-01-06 8:16 UTC (permalink / raw)
To: John Fastabend
Cc: David Miller, edumazet, jasowang, horms, serge.hallyn, netdev,
cgroups, containers, kaber, xemul, ebiederm, linux-kernel, jhs,
lizefan
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff
2014-01-03 5:34 ` David Miller
2014-01-03 6:21 ` John Fastabend
@ 2014-01-07 12:54 ` Libo Chen
1 sibling, 0 replies; 5+ messages in thread
From: Libo Chen @ 2014-01-07 12:54 UTC (permalink / raw)
To: David Miller
Cc: edumazet, jasowang, horms, serge.hallyn, netdev, cgroups,
containers, kaber, xemul, ebiederm, linux-kernel, jhs, lizefan,
Ding Tianhong
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.
>
> .
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-01-07 12:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-03 3:11 [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff Libo Chen
2014-01-03 5:34 ` David Miller
2014-01-03 6:21 ` John Fastabend
2014-01-06 8:16 ` Libo Chen
2014-01-07 12:54 ` Libo Chen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).