Linux Container Development
 help / color / mirror / Atom feed
From: Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
To: "Denis V. Lunev" <den-3ImXcnM4P+0@public.gmane.org>
Cc: xemul-3ImXcnM4P+0@public.gmane.org,
	ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
	containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
	kuznet-v/Mj1YrvjDBInbfyfbPRSQ@public.gmane.org,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
	benjamin.thery-6ktuUTfB/bM@public.gmane.org
Subject: Re: [patch 2/2][NETNS][RFD] use dst_entries to retrieve the network namespace pointer
Date: Wed, 12 Dec 2007 10:03:17 +0100	[thread overview]
Message-ID: <475FA3D5.90900@fr.ibm.com> (raw)
In-Reply-To: <475EC229.8020605-3ImXcnM4P+0@public.gmane.org>

Denis V. Lunev wrote:
> Daniel Lezcano wrote:
>> The objective we have is to remove the fl_net field from the struct flowi.
>>
>> In the previous patch, we make the network namespace to go up to the dst_entry.
>> This patch makes an example in how we can use the dst_entry/rtable combined with
>> a container_of to retrieve the network namespace when we have the flowi parameter.
>>
>> One restriction is we should pass always a flowi parameter coming from a struct
>> dst_entry.
> this is an obfuscation IMHO. You use rtable instead of flowi, so
> - rtable obtain flowi meaning and keeps original meaning
> - stack usage in increased

Yes, you are right. Using container_of is not a good idea finally.

> So, for the case, I think it is better to have an additional parameter
> on IP route output path. (There is a device on the input one).

I thought that at the beginning, but I was not inclined to change 
exported functions API, so I looked a way to avoid that but I failed 
miserably :)
Obviously, the ip route output path extra parameter is the cleanest way 
to introduce the network namespace pointer in the routing code. So why not ?

  parent reply	other threads:[~2007-12-12  9:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-11 13:12 [patch 0/2][NETNS][RFD] moving fl_net to dst_entry Daniel Lezcano
2007-12-11 13:12 ` [patch 1/2][NETNS][RFD] store the network namespace pointer in the dst_entry structure Daniel Lezcano
     [not found]   ` <20071211131749.644219049-K1HbUr/PGdchrHDkVdNya89sqxeZRdF2IBfkmQ/nkib1ENwx4SLHqw@public.gmane.org>
2007-12-11 15:52     ` Eric W. Biederman
     [not found]       ` <m1r6htz0sn.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-12-11 16:14         ` Daniel Lezcano
     [not found]           ` <475EB777.4070704-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-12-11 17:07             ` Eric W. Biederman
     [not found]               ` <m1myshyxbt.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-12-11 17:24                 ` Benjamin Thery
     [not found]                   ` <475EC7B7.1000606-6ktuUTfB/bM@public.gmane.org>
2007-12-11 17:36                     ` Daniel Lezcano
2007-12-11 13:12 ` [patch 2/2][NETNS][RFD] use dst_entries to retrieve the network namespace pointer Daniel Lezcano
     [not found]   ` <20071211131754.788346594-K1HbUr/PGdchrHDkVdNya89sqxeZRdF2IBfkmQ/nkib1ENwx4SLHqw@public.gmane.org>
2007-12-11 17:00     ` Denis V. Lunev
     [not found]       ` <475EC229.8020605-3ImXcnM4P+0@public.gmane.org>
2007-12-11 17:31         ` Eric W. Biederman
2007-12-12  9:03         ` Daniel Lezcano [this message]
     [not found]           ` <475FA3D5.90900-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-12-12  9:26             ` Denis V. Lunev
     [not found]               ` <475FA961.3080605-3ImXcnM4P+0@public.gmane.org>
2007-12-12 11:18                 ` Daniel Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=475FA3D5.90900@fr.ibm.com \
    --to=dlezcano-nmtc/0zbporqt0dzr+alfa@public.gmane.org \
    --cc=benjamin.thery-6ktuUTfB/bM@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=den-3ImXcnM4P+0@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=kuznet-v/Mj1YrvjDBInbfyfbPRSQ@public.gmane.org \
    --cc=xemul-3ImXcnM4P+0@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox