Skip to contentSkip to conversation

net: introduce backup_classid to struct skbuff

RFC PATCH In review Libo Chen 4 participants 6 messages Jan 3, 2014 – Jan 7, 2014 1 message not in the archive

Subsystems (3)
Networking Network drivers cgroup
lore
Share & tools
lore

Libo Chen

author
#0 lore raw

RFC PATCH 1/4 net: introduce backup_classid to struct skbuff

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

Signed-off-by Libo Chen <[email protected]>
---
 include/linux/skbuff.h | 3 +++
 1 file changed, 3 insertions(+)
include/linux/skbuff.h +3 -0
index c5cd016..b76e871 100644
@@ -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;
Signature · 1 line
1.8.2.2
maintainer
#1 lore raw

From: Libo Chen <[email protected]>
Date: Fri, 3 Jan 2014 11:11:04 +0800

Quoted 5 lines

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

Signed-off-by Libo Chen <[email protected]>

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

sk_buff is too big as-is.

#2 lore raw
Quoted 7 lines · David Miller

From: Libo Chen <[email protected]>
Date: Fri, 3 Jan 2014 11:11:04 +0800

Quoted 4 lines

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

Quoted 6 lines
Quoted 1 line
Signed-off-by Libo Chen <[email protected]>

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

Signature · 1 line
John Fastabend         Intel Corporation
author
#3 lore raw
Quoted 13 lines · John Fastabend
Quoted 12 lines · David Miller

From: Libo Chen <[email protected]>
Date: Fri, 3 Jan 2014 11:11:04 +0800

Quoted 5 lines

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

Signed-off-by Libo Chen <[email protected]>

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

Quoted 7 lines
Quoted 1 line

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

Quoted 4 lines

Thanks,
John

author
#4 lore raw
In reply to David Miller
Quoted 4 lines · David Miller

From: Libo Chen <[email protected]>
Date: Fri, 3 Jan 2014 11:11:04 +0800

Quoted 1 line
Quoted 8 lines
Quoted 4 lines

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

Signed-off-by Libo Chen <[email protected]>

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

Quoted 4 lines

sk_buff is too big as-is.

.

A message that is not in the archive (sent off-list or not yet received): 20140103.003404.1439874071277993396.davem-fT/PcQaiUtIeIZ0/[email protected]

#6 lore raw
Quoted 4 lines · David Miller

From: Libo Chen <[email protected]>
Date: Fri, 3 Jan 2014 11:11:04 +0800

Quoted 1 line
Quoted 8 lines
Quoted 4 lines

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

Signed-off-by Libo Chen <[email protected]>

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

Quoted 4 lines

sk_buff is too big as-is.

.