From: Yuval Shaia <yuval.shaia@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Stephen Hemminger <shemminger@vyatta.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
bridge@lists.linux-foundation.org
Subject: Re: [Bridge] [PATCH] Add support for netconsole driver used on bridge device with VIF attached
Date: Mon, 29 Apr 2013 10:42:35 -0000 [thread overview]
Message-ID: <1367232145.26060.1.camel@yuval-pc> (raw)
In-Reply-To: <1359455385.12252.85.camel@zakaz.uk.xensource.com>
On Tue, 2013-01-29 at 10:29 +0000, Ian Campbell wrote:
> On Tue, 2013-01-29 at 08:54 +0000, Yuval Shaia wrote:
> > > Please can you explain the exact code path which results in this new
> > > hook being called.
> > >
> > init_netconsole() in netconsole.c -> alloc_param_target() -> netpoll_setup()
> > in netpoll.c -> __netpoll_setup() which check if ndo_poll_controller()
> > operation is supported.
>
> Are you sure this is being called for the VIF interface? In your
> configuration I'd expect it to be called on the bridge not the vif, or
> at least for calling on the VIF to not impact whether netpool was
> enabled for the bridge or not.
>
> I think the underlying issue which you are seeing is that
> br_netpoll_setup() requires that all members of the bridge support
> netpoll before allowing netpoll to be enabled on the bridge itself.
>
> This seems like an odd restriction in the bridge driver since in
> principal only the port over which the netpoll traffic will be going
> will need netpoll, but perhaps the bridge can't tell which port that is
> or is going to be? I think it is worth discussing this with the bridge
> maintainers (who I have CC'd, threads starts at
> http://marc.info/?l=linux-netdev&m=135878868112700&w=2)
>
> Hopefully the bridge isn't flooding/broadcasting netpoll to all ports,
> at least in the case where DST IP and MAC have been specified. That
> would be rather inefficient, especially when most ports go to virtual
> machines.
>
> So before I ack this patch I'd like to hear back from the bridge
> maintainers about whether the current behaviour in the bridge is
> intended and whether it could be fixed in some better way than adding
> netpoll to netback.
Ian,
Can you suggest how to continue from here? as i don't see any comment on
that issue up to now.
Yuval
>
> AFAICT the only reason to actually support netpoll in netback would be
> if you wanted host logs to go to a listener running in a domain on the
> same host, which sounds like a mad idea to me! If someone actually has a
> real need for that use case and can test that it works I'd be happy to
> reconsider this patch on that basis (assuming the necessary #ifdefs are
> added as mentioned before).
>
> > > BTW looking at the patch as it is any use of this hook should be wrapped
> > > in CONFIG_NET_POLL_CONTROLLER.
> > >
> > > Ian.
> > >
> >
> >
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Yuval Shaia <yuval.shaia@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
bridge@lists.linux-foundation.org,
Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: [PATCH] Add support for netconsole driver used on bridge device with VIF attached
Date: Mon, 29 Apr 2013 13:42:25 +0300 [thread overview]
Message-ID: <1367232145.26060.1.camel@yuval-pc> (raw)
In-Reply-To: <1359455385.12252.85.camel@zakaz.uk.xensource.com>
On Tue, 2013-01-29 at 10:29 +0000, Ian Campbell wrote:
> On Tue, 2013-01-29 at 08:54 +0000, Yuval Shaia wrote:
> > > Please can you explain the exact code path which results in this new
> > > hook being called.
> > >
> > init_netconsole() in netconsole.c -> alloc_param_target() -> netpoll_setup()
> > in netpoll.c -> __netpoll_setup() which check if ndo_poll_controller()
> > operation is supported.
>
> Are you sure this is being called for the VIF interface? In your
> configuration I'd expect it to be called on the bridge not the vif, or
> at least for calling on the VIF to not impact whether netpool was
> enabled for the bridge or not.
>
> I think the underlying issue which you are seeing is that
> br_netpoll_setup() requires that all members of the bridge support
> netpoll before allowing netpoll to be enabled on the bridge itself.
>
> This seems like an odd restriction in the bridge driver since in
> principal only the port over which the netpoll traffic will be going
> will need netpoll, but perhaps the bridge can't tell which port that is
> or is going to be? I think it is worth discussing this with the bridge
> maintainers (who I have CC'd, threads starts at
> http://marc.info/?l=linux-netdev&m=135878868112700&w=2)
>
> Hopefully the bridge isn't flooding/broadcasting netpoll to all ports,
> at least in the case where DST IP and MAC have been specified. That
> would be rather inefficient, especially when most ports go to virtual
> machines.
>
> So before I ack this patch I'd like to hear back from the bridge
> maintainers about whether the current behaviour in the bridge is
> intended and whether it could be fixed in some better way than adding
> netpoll to netback.
Ian,
Can you suggest how to continue from here? as i don't see any comment on
that issue up to now.
Yuval
>
> AFAICT the only reason to actually support netpoll in netback would be
> if you wanted host logs to go to a listener running in a domain on the
> same host, which sounds like a mad idea to me! If someone actually has a
> real need for that use case and can test that it works I'd be happy to
> reconsider this patch on that basis (assuming the necessary #ifdefs are
> added as mentioned before).
>
> > > BTW looking at the patch as it is any use of this hook should be wrapped
> > > in CONFIG_NET_POLL_CONTROLLER.
> > >
> > > Ian.
> > >
> >
> >
>
>
next prev parent reply other threads:[~2013-04-29 10:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 17:17 [PATCH] Add support for netconsole driver used on bridge device with VIF attached Yuval Shaia
2013-01-21 17:17 ` Yuval Shaia
2013-01-21 17:28 ` Ian Campbell
2013-01-21 18:00 ` yuval.shaia
2013-01-22 9:23 ` Ian Campbell
2013-01-29 8:47 ` yuval.shaia
2013-01-29 8:54 ` Yuval Shaia
2013-01-29 10:29 ` [Bridge] " Ian Campbell
2013-01-29 10:29 ` Ian Campbell
2013-01-29 10:29 ` Ian Campbell
2013-04-29 10:42 ` Yuval Shaia [this message]
2013-04-29 10:42 ` [Bridge] " Yuval Shaia
2013-04-30 14:24 ` Ian Campbell
2013-04-30 14:24 ` Ian Campbell
-- strict thread matches above, loose matches on Subject: below --
2013-05-01 11:55 [Bridge] " Yuval Shaia
2013-05-03 9:11 ` Ian Campbell
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=1367232145.26060.1.camel@yuval-pc \
--to=yuval.shaia@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=bridge@lists.linux-foundation.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=xen-devel@lists.xensource.com \
/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.