On Wed, Aug 09, 2017 at 06:27:32PM +0300, Feras Daoud wrote:
> The current implementation of ptp4l always assumes 6 octets MAC
> address, which is correct for Ethernet interfaces but not for IPoIB
> interfaces (that have 20 octets MAC), therefore running ptp4l over
> IPoIB interface does not functi
The current implementation of ptp4l always assumes 6 octets MAC
address, which is correct for Ethernet interfaces but not for IPoIB
interfaces (that have 20 octets MAC), therefore running ptp4l over
IPoIB interface does not function correctly.
In Infiniband, every interface has three identifiers:
Looks good now, except for a couple of nits...
On Tue, Aug 08, 2017 at 10:50:35AM +0300, Feras Daoud wrote:
> +static int sk_interface_guidaddr(const char *name, unsigned char *guid)
> +{
> + char file_name[64], buf[64], addr[8];
> + FILE *f;
> + int rc;
> +
> + snprintf(file_name,
The current implementation of ptp4l always assumes 6 octets MAC
address, which is correct for Ethernet interfaces but not for IPoIB
interfaces (that have 20 octets MAC), therefore running ptp4l over
IPoIB interface does not function correctly.
In Infiniband, every interface has three identifiers:
On 8/7/2017 4:56 PM, Richard Cochran wrote:
Sorry for the long wait on feedback. This patchs looks okay, but I do
have a few nits to pick...
Thanks for your reply, I will send a new patch with the fixes.
On Mon, Jul 24, 2017 at 05:07:46PM +0300, Feras Daoud wrote:
diff --git a/raw.c b/raw
On Mon, Aug 07, 2017 at 05:25:18PM +0300, Feras Daoud wrote:
> Right, SIOCGIFHWADDR ioctl call returns the 14 msb bytes of the device
> address.
> In our case, the GUID is the 6 lsb bytes of the 20 byte device address, so
> it is not possible
> to get the GUID using SIOCGIFHWADDR ioctl call.
Ok.
On 8/7/2017 4:58 PM, Richard Cochran wrote:
On Mon, Jul 24, 2017 at 05:07:46PM +0300, Feras Daoud wrote:
In Infiniband, every interface has three identifiers:
GUID, GID, and LID.
The GUID is similar in concept to a MAC address. From RFC4392:
The EUI-64 portion of a GID is referred to as the Gl
On Mon, Jul 24, 2017 at 05:07:46PM +0300, Feras Daoud wrote:
> In Infiniband, every interface has three identifiers:
> GUID, GID, and LID.
> The GUID is similar in concept to a MAC address. From RFC4392:
> The EUI-64 portion of a GID is referred to as the Global Unique
> Identifier (GUID) and is th
Sorry for the long wait on feedback. This patchs looks okay, but I do
have a few nits to pick...
On Mon, Jul 24, 2017 at 05:07:46PM +0300, Feras Daoud wrote:
> diff --git a/raw.c b/raw.c
> index 73e45b45bd25..559c93315154 100644
> --- a/raw.c
> +++ b/raw.c
> @@ -220,7 +220,7 @@ static int raw_op
On Tue, Aug 01, 2017 at 10:45:54AM +0300, Feras Daoud wrote:
> Since this patch transfer ptp4l from non-working state to properly working
> for those interfaces, I would like to see it is accepted, so other
> infiniband users will enjoy from such functionality.
It is on my todo list.
Thanks,
Rich
Hi Richard,
This patch came after our discussion on linuxptp-users list [1], where
the issue was raised that ptp4l doesn’t work with Infiniband interfaces.
Since this patch transfer ptp4l from non-working state to properly
working for those interfaces, I would like to see it is accepted, so o
The current implementation of ptp4l always assumes 6 octets MAC
address, which is correct for Ethernet interfaces but not for IPoIB
interfaces (that have 20 octets MAC), therefore running ptp4l over
IPoIB interface does not function correctly.
In Infiniband, every interface has three identifiers:
The current implementation of ptp4l always assumes 6 octets MAC
address, which is correct for Ethernet interfaces but not for IPoIB
interfaces (that have 20 octets MAC), therefore running ptp4l over
IPoIB interface does not function correctly.
In Infiniband, every interface has three identifiers:
13 matches
Mail list logo
