From: Richard Cochran <richardcochran@gmail.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: linux-net-drivers <linux-net-drivers@solarflare.com>,
netdev <netdev@vger.kernel.org>
Subject: Re: PHC device sharing between PCI functions
Date: Tue, 2 Jul 2013 16:24:20 +0200 [thread overview]
Message-ID: <20130702142420.GC14630@netboy> (raw)
In-Reply-To: <1372697768.2083.21.camel@bwh-desktop.uk.level5networks.com>
Ben,
I really don't understand what the use case is...
On Mon, Jul 01, 2013 at 05:56:08PM +0100, Ben Hutchings wrote:
> Future Solarflare NICs may allow multiple PCI functions to make use of a
> PTP hardware clock, but without a separate clock per function (probably
> only one per controller).
>
> I understand that shared PTP hardware clocks already exist, but they
> usually have an independent existence as a separate PCI or platform
> device. In this case the clock would be accessible through any of the
> PCI functions that also have a net device.
>
> Options I see are:
>
> 1. Instantiate a clock only for the first function. But that would
> preclude making the clock available within multiple VMs and their host.
So, I guess PCI functions on one card may be divided up among the
guests in a VM environment?
Even if you did make your one clock visible to mutiple guests, still
only one would be able to adjust the clock, right?
And if so, then how will the mutiple, read-only MAC clocks help other
guests? Seems kinda useless to me.
> 3. Keep track of controllers in the driver, instantiate a 'platform
> device' for each of them, and instantiate a clock for each of them.
> This is a little weird, as it wouldn't have any obvious association to
> the PCI device hierarchy. But it would let us control the lifetime of
> the clock devices independently of any one function.
I think clock and MAC must go hand in hand. Does one card appear as a
MAC in more than one VM?
> I prefer option 3 as I dislike introducing special cases, but I would be
> interested to hear your (or other people's) opinion on this.
Sorry, my brain just isn't letting any of this in.
Thanks,
Richard
next prev parent reply other threads:[~2013-07-02 14:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 16:56 PHC device sharing between PCI functions Ben Hutchings
2013-07-02 14:24 ` Richard Cochran [this message]
2013-07-02 15:17 ` Ben Hutchings
2013-07-03 18:30 ` Richard Cochran
2013-07-03 19:52 ` Ben Hutchings
2013-07-04 5:36 ` Richard Cochran
2013-07-04 14:34 ` Ben Hutchings
2013-07-04 15:53 ` Richard Cochran
2013-07-04 16:21 ` Ben Hutchings
2013-07-04 17:39 ` Richard Cochran
2013-07-04 18:19 ` Ben Hutchings
2013-07-05 5:25 ` Richard Cochran
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=20130702142420.GC14630@netboy \
--to=richardcochran@gmail.com \
--cc=bhutchings@solarflare.com \
--cc=linux-net-drivers@solarflare.com \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).