From: Ben Hutchings <bhutchings@solarflare.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [ethtool PATCH 6/6] Update documentation for -u/-U operations
Date: Fri, 29 Apr 2011 03:57:42 +0100 [thread overview]
Message-ID: <1304045862.3105.6.camel@localhost> (raw)
In-Reply-To: <4DB9D0D9.2000401@intel.com>
On Thu, 2011-04-28 at 13:40 -0700, Alexander Duyck wrote:
> On 4/27/2011 11:23 AM, Ben Hutchings wrote:
> > On Thu, 2011-04-21 at 13:40 -0700, Alexander Duyck wrote:
[...]
> >> --- a/ethtool.8.in
> >> +++ b/ethtool.8.in
> >> @@ -42,10 +42,20 @@
> >> [\\fB\\$1\\fP\ \\fIN\\fP]
> >> ..
> >> .\"
> >> +.\" .BM - same as above but has a mask field for format "[value N [value-mask N]]"
> >> +.\"
> >> +.de BM
> >> +[\\fB\\$1\\fP\ \\fIN\\fP\ [\\fB\\$1\-mask\\fP\ \\fIN\\fP]]
> >
> > You've changed the code to accept 'm' as an alternative to
> > <field> '-mask', so this should be changed accordingly.
>
> What would be the preferred way of stating that? For now I just
> replaced the \\$1\-mask with m. However I am assuming that probably
> isn't the best approach either. Should I state somewhere that m can be
> replaced with "field name"-mask?
I think that's reasonable.
[...]
> >> +.BN class-rule-del
> >> +.RB [\ flow-type \ \*(NC
> >> +.RB [ src \ \*(MA\ [ src-mask \ \*(MA]]
> >> +.RB [ dst \ \*(MA\ [ dst-mask \ \*(MA]]
> >> +.BM proto
> >> +.RB [ src-ip \ \*(PA\ [ src-ip-mask \ \*(PA]]
> >> +.RB [ dst-ip \ \*(PA\ [ dst-ip-mask \ \*(PA]]
> >> +.BM tos
> >> +.BM l4proto
> >> +.BM src-port
> >> +.BM dst-port
> >> +.BM spi
> >> +.BM vlan-etype
> >> +.BM vlan
> >> +.BM user-def
> >> +.BN action
> >> +.BN loc
> >> +.RB ]
> >
> > But these options aren't all applicable to all flow-types.
>
> This is the part that gets messy and I am not sure what the best
> approach is. I have more comments on that below. For now what I am
> planning to implement to address this is that in the "DESCRIPTION"
> section below I add a statement to each specifier that has restrictions
> by stating "Valid for flow-types X, Y, and Z."
OK.
> > [...]
> >> diff --git a/ethtool.c b/ethtool.c
> >> index 421fe20..e65979d 100644
> >> --- a/ethtool.c
> >> +++ b/ethtool.c
> >> @@ -243,20 +243,26 @@ static struct option {
> >> " equal N | weight W0 W1 ...\n" },
> >> { "-U", "--config-ntuple", MODE_SCLSRULE, "Configure Rx ntuple filters "
> >> "and actions",
> >> - " { flow-type tcp4|udp4|sctp4\n"
> >> - " [ src-ip ADDR [src-ip-mask MASK] ]\n"
> >> - " [ dst-ip ADDR [dst-ip-mask MASK] ]\n"
> >> - " [ src-port PORT [src-port-mask MASK] ]\n"
> >> - " [ dst-port PORT [dst-port-mask MASK] ]\n"
> >> - " | flow-type ether\n"
> >> - " [ src MAC-ADDR [src-mask MASK] ]\n"
> >> - " [ dst MAC-ADDR [dst-mask MASK] ]\n"
> >> - " [ proto N [proto-mask MASK] ] }\n"
> >> - " [ vlan VLAN-TAG [vlan-mask MASK] ]\n"
> >> - " [ user-def DATA [user-def-mask MASK] ]\n"
> >> - " action N\n" },
> >> + " [ class-rule-del %d ] |\n"
> >> + " [ flow-type ether|ip4|tcp4|udp4|sctp4|ah4|esp4\n"
> >> + " [ src %x:%x:%x:%x:%x:%x [src-mask %x:%x:%x:%x:%x:%x] ]\n"
> >> + " [ dst %x:%x:%x:%x:%x:%x [dst-mask %x:%x:%x:%x:%x:%x] ]\n"
> >> + " [ proto %d [proto-mask MASK] ]\n"
> >> + " [ src-ip %d.%d.%d.%d [src-ip-mask %d.%d.%d.%d] ]\n"
> >> + " [ dst-ip %d.%d.%d.%d [dst-ip-mask %d.%d.%d.%d] ]\n"
> >> + " [ tos %d [tos-mask %x] ]\n"
> >> + " [ l4proto %d [l4proto-mask MASK] ]\n"
> >> + " [ src-port %d [src-port-mask %x] ]\n"
> >> + " [ dst-port %d [dst-port-mask %x] ]\n"
> >> + " [ spi %d [spi-mask %x] ]\n"
> >> + " [ vlan-etype %x [vlan-etype-mask %x] ]\n"
> >> + " [ vlan %x [vlan-mask %x] ]\n"
> >> + " [ user-def %x [user-def-mask %x] ]\n"
> >> + " [ action %d ]\n"
> >> + " [ loc %d]]\n" },
> > [...]
> >
> > Again, it's not clear which options apply to which flow-types, and the
> > 'm' shortcut is not documented.
>
> The 'm' part I agree with 100%, however the flow types are going to
> become kinda hairy using that approach. You basically end up with
> something like this:
[...]
Yes, I see the problem.
> As you can see it will be a bit oversized to go through and specify
> which flow-type options support what fields. If that is what you want I
> can implement it that way but for now I would prefer calling out the
> flow-type limitations of the fields in the "DESCRIPTION" portion of the
> man page.
In fact, even with this patch, the help for -U is pretty oversized. It
might be better to replace the list of field names with '...' here and
only list them in full in the man page.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2011-04-29 2:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 20:40 [ethtool PATCH 0/6] Network flow classifier Alexander Duyck
2011-04-21 20:40 ` [ethtool PATCH 1/6] Add support for ESP as a separate protocol from AH Alexander Duyck
2011-04-27 15:47 ` Ben Hutchings
2011-04-21 20:40 ` [ethtool PATCH 2/6] Add support for NFC flow classifier extensions Alexander Duyck
2011-04-27 15:48 ` Ben Hutchings
2011-04-21 20:40 ` [ethtool PATCH 3/6] ethtool: remove strings based approach for displaying n-tuple Alexander Duyck
2011-04-27 18:12 ` Ben Hutchings
2011-04-21 20:40 ` [ethtool PATCH 4/6] Add support for __be64 and bitops to ethtool Alexander Duyck
2011-04-27 15:54 ` Ben Hutchings
2011-04-27 16:46 ` Alexander Duyck
2011-04-27 17:09 ` Ben Hutchings
2011-04-27 18:33 ` Alexander Duyck
2011-04-21 20:40 ` [ethtool PATCH 5/6] v4 Add RX packet classification interface Alexander Duyck
2011-04-27 18:12 ` Ben Hutchings
2011-04-27 23:00 ` Ben Hutchings
2011-04-28 20:15 ` Alexander Duyck
2011-04-21 20:40 ` [ethtool PATCH 6/6] Update documentation for -u/-U operations Alexander Duyck
2011-04-27 18:23 ` Ben Hutchings
2011-04-28 20:40 ` Alexander Duyck
2011-04-29 2:57 ` Ben Hutchings [this message]
2011-04-21 20:51 ` [ethtool PATCH 0/6] Network flow classifier Ben Hutchings
2011-04-21 21:11 ` Alexander Duyck
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=1304045862.3105.6.camel@localhost \
--to=bhutchings@solarflare.com \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.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).