Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

[Richard Cochran]

On Wed, Mar 11, 2015 at 11:20:59AM +0000, Stathis Voukelatos wrote:
> Our feeling is that we will have to test and verify that a move to gPTP
> will fit with the use cases that we have to support and that will
> require a fair amount of effort and rewrite of application software.
> If the driver is not acceptable with the current interface we may need
> to maintain it as a private patch until we are ready to move to gPTP
> as you recommend.

Sure, there is nothing wrong with that.  For the kernel, we want to
build good interfaces for future applications.  Sometimes reworking
the applications that use the old, private interfaces is just too much
work, so you have to maintain those interfaces in your products.

> I was referring to the Songcast protocol we are using which is part
> of the OpenHome suite (www.openhome.org) and runs on top of UDP.
> It could be filtered by testing the first 5 bytes of the payload.

Sounds promising.

> In our implementation we also add the destination IP and port to
> the filter to make it more reliable, but hwtstamp_rx_filters cannot
> accept parameters.

If the IP is a defined multicast group address, and if the port is
well a known port, then you should of course include them in the
driver level filter.

Adding a unicast destination IP doesn't make it more reliable, because
frames addressed to other hosts are switched away from the host (or
dropped by the MAC).

> However, I will test that and maybe come back with
> a patch to expand the hwtstamp_rx_filter enum initially?

It probably makes more sense to present the expanded filter list in
the same patch series with the new driver that uses it, in order to
see the context.  So I would hold off posting until both are ready.

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/