| Message ID | 52C62A48.1050604@huawei.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
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 unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. > > . > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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;
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(+)