From: Johannes Berg <johannes@sipsolutions.net>
To: Sabrina Dubroca <sd@queasysnail.net>, netdev@vger.kernel.org
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
Florian Westphal <fw@strlen.de>, Paolo Abeni <pabeni@redhat.com>,
stephen@networkplumber.org
Subject: Re: [PATCH net-next 1/3] uapi: add MACsec bits
Date: Tue, 08 Mar 2016 20:52:48 +0100 [thread overview]
Message-ID: <1457466768.24270.24.camel@sipsolutions.net> (raw)
In-Reply-To: <08d3b90c1577276ccbb8ae1794f8c9842df5222d.1456937772.git.sd@queasysnail.net> (sfid-20160307_181300_785922_47902293)
On Mon, 2016-03-07 at 18:12 +0100, Sabrina Dubroca wrote:
> +++ b/include/uapi/linux/if_macsec.h
Some bits of documentation in this file, regarding all the various
operations and attributes, might be nice. At least the netlink types?
E.g., given this:
> +#define DEFAULT_CIPHER_NAME "GCM-AES-128"
> +#define DEFAULT_CIPHER_ID 0x0080020001000001ULL
> +#define DEFAULT_CIPHER_ALT 0x0080C20001000001ULL
> +enum macsec_attrs {
[...]
> + MACSEC_ATTR_CIPHER_SUITE,
should that be the ID, the alternate ID, or the string?
> + MACSEC_ATTR_ICV_LEN,
> + MACSEC_TXSA_LIST,
> + MACSEC_RXSC_LIST,
> + MACSEC_TXSC_STATS,
> + MACSEC_SECY_STATS,
> + MACSEC_ATTR_PROTECT,
This seems a bit inconsistent, MACSEC_ATTR_* vs. MACSEC_*?
> +enum macsec_sa_list_attrs {
> + MACSEC_SA_LIST_UNSPEC,
> + MACSEC_SA,
> + __MACSEC_ATTR_SA_LIST_MAX,
> + MACSEC_ATTR_SA_LIST_MAX = __MACSEC_ATTR_SA_LIST_MAX - 1,
> +};
Again, without documentation, it seems odd to have an enum with just a
single useful entry? If you just wanted an array you don't need this at
all? The netlink nesting properties could be specified somewhere.
> +enum macsec_rxsc_list_attrs {
> + MACSEC_RXSC_LIST_UNSPEC,
> + MACSEC_RXSC,
similarly here
> +enum macsec_rxsc_attrs {
> + MACSEC_ATTR_SC_UNSPEC,
> + /* use the same value to allow generic helper function, see
> + * get_*_from_nl in drivers/net/macsec.c */
> + MACSEC_ATTR_SC_IFINDEX = MACSEC_ATTR_IFINDEX,
> + MACSEC_ATTR_SC_SCI = MACSEC_ATTR_SCI,
This seems odd, this must be nested inside the top-level attributes
since it's a single genl family, so why not use the top-level
attributes to start with?
If you need multiple you can use dump with multiple messages.
> +enum macsec_sa_attrs {
> + MACSEC_ATTR_SA_UNSPEC,
> + /* use the same value to allow generic helper function, see
> + * get_*_from_nl in drivers/net/macsec.c */
> + MACSEC_ATTR_SA_IFINDEX = MACSEC_ATTR_IFINDEX,
> + MACSEC_ATTR_SA_SCI = MACSEC_ATTR_SCI,
likewise here
> +enum validation_type {
> + MACSEC_VALIDATE_DISABLED = 0,
> + MACSEC_VALIDATE_CHECK = 1,
> + MACSEC_VALIDATE_STRICT = 2,
> + __MACSEC_VALIDATE_MAX,
> +};
> +#define MACSEC_VALIDATE_MAX (__MACSEC_VALIDATE_MAX - 1)
everywhere else you put that into the enum, why not here?
> +struct macsec_rx_sc_stats {
> + __u64 InOctetsValidated;
> + __u64 InOctetsDecrypted;
> + __u64 InPktsUnchecked;
> + __u64 InPktsDelayed;
> + __u64 InPktsOK;
> + __u64 InPktsInvalid;
> + __u64 InPktsLate;
> + __u64 InPktsNotValid;
> + __u64 InPktsNotUsingSA;
> + __u64 InPktsUnusedSA;
> +};
It might be worth splitting those into attributes so that, if some
hardware offload can't provide all of the counters in the future, they
can just be left out of the netlink message?
johannes
next prev parent reply other threads:[~2016-03-08 19:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 17:12 [PATCH net-next 0/3] MACsec IEEE 802.1AE implementation Sabrina Dubroca
2016-03-07 17:12 ` [PATCH net-next 1/3] uapi: add MACsec bits Sabrina Dubroca
2016-03-08 19:52 ` Johannes Berg [this message]
2016-03-09 10:51 ` Sabrina Dubroca
2016-03-09 11:34 ` Johannes Berg
2016-03-10 9:55 ` Sabrina Dubroca
2016-03-07 17:12 ` [PATCH net-next 2/3] net: add MACsec netdevice priv_flags and helper Sabrina Dubroca
2016-03-07 17:12 ` [PATCH net-next 3/3] macsec: introduce IEEE 802.1AE driver Sabrina Dubroca
2016-03-07 19:05 ` David Miller
2016-03-08 20:13 ` Johannes Berg
2016-03-09 10:56 ` Sabrina Dubroca
2016-03-09 11:24 ` Johannes Berg
2016-03-09 17:09 ` David Miller
2016-03-07 17:12 ` [PATCH iproute2 net-next] ip: add MACsec support Sabrina Dubroca
2016-03-07 19:48 ` Stephen Hemminger
2016-03-08 10:49 ` Sabrina Dubroca
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1457466768.24270.24.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=fw@strlen.de \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).