On Tue, Jan 31, 2017 at 03:08:11PM +, Mintz, Yuval wrote:
> While it surely answers my question, I still don't think of an event
> reoccurring 16 times a second as optimization-crucial.
> Is there any reasonable scenario where the interval is
> significantly smaller, or is it merely some theore
> > I feel like I'm missing something. Again.
> > I thought the reasonable rate of rate-adjustment is once a second,
> > which doesn't make it 'hot' in any way.
> > In which scenario would we frequently encounter this configuration?
>
> The Sync message rate is not 1 per second, but rather the int
On Tue, Jan 31, 2017 at 02:31:41PM +, Mintz, Yuval wrote:
> I feel like I'm missing something. Again.
> I thought the reasonable rate of rate-adjustment is once a second,
> which doesn't make it 'hot' in any way.
> In which scenario would we frequently encounter this configuration?
The Sync me
> > > How many different implementations of 'ops->adjfreq' are there?
> > > If there is only one you don't need an indirect call.
> >
> > There's only one implementation. But qed publishes its functions to
> > qede [and other modules] by structs of operations and not by exporting
> > symbols direct
From: Mintz, Yuval
> Sent: 30 January 2017 17:56
> > How many different implementations of 'ops->adjfreq' are there?
> > If there is only one you don't need an indirect call.
>
> There's only one implementation. But qed publishes its functions to
> qede [and other modules] by structs of operations
> How many different implementations of 'ops->adjfreq' are there?
> If there is only one you don't need an indirect call.
There's only one implementation. But qed publishes its functions to
qede [and other modules] by structs of operations and not by
exporting symbols directly, and I don't see a r
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
Behalf Of Richard Cochran
> Sent: 29 January 2017 15:36
...
> > +static int qede_ptp_adjfreq(struct ptp_clock_info *info, s32 ppb)
> > +{
> > + struct qede_ptp *ptp = container_of(info, struct qede_ptp, clock_info);
> >
> > That's part of the driver structuring - qed is responsible for
> > accessing HW so it implements api functions for accessing PTP-related
> > configuration, while qede is responsible for the network interface and
> > thus is the one to register the clock and implements its API.
>
> But there is
On Sun, Jan 29, 2017 at 05:30:51PM +, Mintz, Yuval wrote:
> That's part of the driver structuring - qed is responsible for accessing HW
> so it implements api functions for accessing PTP-related configuration,
> while qede is responsible for the network interface and thus is the one to
> regist
> > +static int qede_ptp_adjfreq(struct ptp_clock_info *info, s32 ppb) {
> > + struct qede_ptp *ptp = container_of(info, struct qede_ptp,
> clock_info);
> > + struct qede_dev *edev = ptp->edev;
> > + int rc;
> > +
> > + __qede_lock(edev);
> > + if (edev->state == QEDE_STATE_OPEN) {
> > +
On Sat, Jan 28, 2017 at 11:28:23PM -0800, Sudarsana Kalluru wrote:
> +/**
> + * qede_ptp_adjfreq
> + * @ptp: the ptp clock structure
> + * @ppb: parts per billion adjustment from base
> + *
> + * Adjust the frequency of the ptp cycle counter by the
> + * indicated ppb from the base frequency.
> + *
From: Sudarsana Reddy Kalluru
This patch adds the driver support for,
- Registering the ptp clock functionality with the OS.
- Timestamping the Rx/Tx PTP packets.
- Ethtool callbacks related to PTP.
Signed-off-by: Sudarsana Reddy Kalluru
Signed-off-by: Yuval Mintz
---
drivers/net/ethern
12 matches
Mail list logo
