Re: [RFC][PATCH 1/1] net: support for hardware timestamping

[Patrick Ohly <patrick.ohly@intel.com>]

On Wed, 2008-07-30 at 16:38 +0300, Octavian Purdila wrote:
> On Wednesday 30 July 2008, Patrick Ohly wrote:
> 
> > It's the app which chooses when to enable the feature, so we need a way
> > to communicate that.
> 
> Ok, perhaps a new SIOCSHWTSTAMP ioctl? (or maybe we can piggy back on the 
> filter one with the HWTSTAMP_FILTER_NONE you proposed?)

I'm fine with just one ioctl and would prefer a generic SIOCSHWTSTAMP. I
would like to go even one step further than discussed so far and also
use it to enable TX time stamping. The reasoning is that the driver
might have to do some work (like initializing the NIC clock, setting up
NIC/system time comparison) both for TX and RX.

That means that we need two fields and defines for TX. Adding new fields
later on works, but having to support multiple different sizes in the
driver could get complicated, so I suggest to add at least a (currently
unused) flag field. Not sure what the usual convention is regarding the
type fields - char or int?

struct hwtstamp_config {
    char tx_type;
    char rx_filter_type;
    int flags;
};

/**
 * no outgoing packet will need hardware time stamping;
 * should a packet arrive which asks for it, no hardware
 * time stamping will be done
 */
#define HWTSTAMP_TX_OFF 0

/**
 * enables hardware time stamping for outgoing packets;
 * the sender of the packet decides which are to be 
 * time stamped
 */
#define HWSTAMP_TX_ON 1

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.