LKML Archive on
help / color / mirror / Atom feed
From: Stathis Voukelatos <>
To: Daniel Borkmann <>,
	<>, <>,
Cc: <>, <>
Subject: Re: [PATCH v2 2/3] Packet sniffer core framework
Date: Wed, 18 Feb 2015 16:44:19 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Daniel,

On 18/02/15 15:42, Daniel Borkmann wrote:
> This whole framework really looks like only tailored to your specific
> driver, I have no idea who else should reuse that?! So, I don't think
> putting this under drivers/net/pkt-sniffer/ is a good idea.

Yes, it is not necessarilly expected to be used by other 3rd party 
drivers. The reason of splitting out the framework code is to account of 
the fact the we may develop in the future othersimilar sniffer H/W for 
non-ethernet interfaces (eg. wifi).
I can move the code under drivers/net/ethernet/linn as you mention 
below, although that may not account for non-ethernet backends in the

> Also it looks slightly confusing as if I understand you correctly, your
> module's purpose is to pass down some "packet pattern" to the hardware
> and match that in order to get a precise timestamp in return?

Yes, this point can be slightly confusing. A write to a packet socket 
bound to the interface is done to supply the command string to the 
sniffer H/W, while reads would return matched packet bytes + timestamps 
(throuch cmsg). Is there any other way to supply the command string 
except of a proprietary ioctl?

> Might perhaps be better to have everything vendor-specific under something
> like drivers/net/ethernet/linn/ and have the framework squashed into the
> driver itself (if parts cannot be generalized in net/packet/).

Answered above.

> It would be good if you can also avoid the extra uapi export. Perhaps
> it's possible to reuse at least some of the existing timestamping
> infrastructure?

I can remove that. The header file only contains the list of commands.
They can be documented. The driver does use the existing timestamping
infrastructure to return timestamps to user space.

Thank you,

  reply	other threads:[~2015-02-18 16:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 14:03 [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 1/3] Ethernet packet sniffer: Device tree binding and vendor prefix Stathis Voukelatos
2015-02-17 14:16   ` Sergei Shtylyov
2015-02-17 14:51   ` Mark Rutland
2015-02-17 16:22     ` Stathis Voukelatos
2015-02-17 16:35       ` Mark Rutland
2015-02-17 17:13         ` Stathis Voukelatos
2015-02-17 17:30           ` Mark Rutland
2015-02-18  9:40             ` Stathis Voukelatos
2015-02-18 12:11               ` Mark Rutland
2015-02-18 13:56                 ` Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 2/3] Packet sniffer core framework Stathis Voukelatos
2015-02-18 15:42   ` Daniel Borkmann
2015-02-18 16:44     ` Stathis Voukelatos [this message]
2015-02-17 14:03 ` [PATCH v2 3/3] Linn Ethernet packet sniffer driver Stathis Voukelatos
2015-02-18 21:08 ` [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Richard Cochran
2015-02-23  9:37   ` Stathis Voukelatos
2015-02-25  9:50     ` Richard Cochran
2015-02-25 10:53       ` Stathis Voukelatos
2015-02-25 14:21         ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 2/3] Packet sniffer core framework' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).