All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.