From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend Subject: Re: [RFC PATCH net-next 1/4] net: introduce backup_classid to struct skbuff Date: Thu, 02 Jan 2014 22:21:38 -0800 Message-ID: <52C656F2.8060803@gmail.com> References: <52C62A48.1050604@huawei.com> <20140103.003404.1439874071277993396.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org, edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org, ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, David Miller , xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org To: clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org Return-path: In-Reply-To: <20140103.003404.1439874071277993396.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: netdev.vger.kernel.org On 01/02/2014 09:34 PM, David Miller wrote: > From: Libo Chen > 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 > > 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