All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>,
	ldir@darbyshire-bryant.me.uk
Cc: netdev@vger.kernel.org, stephen@networkplumber.org
Subject: Re: [PATCH RFC iproute2-next v4] tc: add support for action act_ctinfo
Date: Mon, 03 Jun 2019 22:14:15 +0200	[thread overview]
Message-ID: <87y32ifmug.fsf@toke.dk> (raw)
In-Reply-To: <20190603135040.75408-1-ldir@darbyshire-bryant.me.uk>

Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk> writes:

> ctinfo is an action restoring data stored in conntrack marks to various
> fields.  At present it has two independent modes of operation,
> restoration of DSCP into IPv4/v6 diffserv and restoration of conntrack
> marks into packet skb marks.
>
> It understands a number of parameters specific to this action in
> additional to the usual action syntax.  Each operating mode is
> independent of the other so all options are optional, however not
> specifying at least one mode is a bit pointless.
>
> Usage: ... ctinfo [dscp mask [statemask]] [cpmark [mask]] [zone ZONE]
> 		  [CONTROL] [index <INDEX>]
>
> DSCP mode
>
> dscp enables copying of a DSCP store in the conntrack mark into the
> ipv4/v6 diffserv field.  The mask is a 32bit field and specifies where
> in the conntrack mark the DSCP value is stored.  It must be 6 contiguous
> bits long, e.g. 0xfc000000 would restore the DSCP from the upper 6 bits
> of the conntrack mark.
>
> The DSCP copying may be optionally controlled by a statemask.  The
> statemask is a 32bit field, usually with a single bit set and must not
> overlap the dscp mask.  The DSCP restore operation will only take place
> if the corresponding bit/s in conntrack mark yield a non zero result.
>
> eg. dscp 0xfc000000/0x01000000 would retrieve the DSCP from the top 6
> bits, whilst using bit 25 as a flag to do so.  Bit 26 is unused in this
> example.
>
> CPMARK mode
>
> cpmark enables copying of the conntrack mark to the packet skb mark.  In
> this mode it is completely equivalent to the existing act_connmark.
> Additional functionality is provided by the optional mask parameter,
> whereby the stored conntrack mark is logically anded with the cpmark
> mask before being stored into skb mark.  This allows shared usage of the
> conntrack mark between applications.
>
> eg. cpmark 0x00ffffff would restore only the lower 24 bits of the
> conntrack mark, thus may be useful in the event that the upper 8 bits
> are used by the DSCP function.
>
> Usage: ... ctinfo [dscp mask [statemask]] [cpmark [mask]] [zone ZONE]
> 		  [CONTROL] [index <INDEX>]
> where :
> 	dscp MASK is the bitmask to restore DSCP
> 	     STATEMASK is the bitmask to determine conditional restoring
> 	cpmark MASK mask applied to restored packet mark
> 	ZONE is the conntrack zone
> 	CONTROL := reclassify | pipe | drop | continue | ok |
> 		   goto chain <CHAIN_INDEX>
>
> Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
>
> ---
> v2 - fix whitespace issue in pkt_cls
>      fix most warnings from checkpatch - some lines still over 80 chars
>      due to long TLV names.
> v3 - fix some dangling else warnings.
>      refactor stats printing to please checkpatch.
>      send zone TLV even if default '0' zone.
>      now checkpatch clean even though I think some of the formatting
>      is horrible :-)
>      sending via google's smtp 'cos MS' exchange office365 appears
>      to mangle patches from git send-email.
> v4 - use the NEXT_ARG macros throughout.
>      fix printing typo use 'cpmark' instead of 'mark'.
>      use space separator between dscp mask & optional statemask and
>      update usage as a result.
>      validate dscp mask & statemask and print friendlier warnings
>      than "invalid".
>      fix cpmark option default value handling bug.

No further comments on this version; you should probably re-submit
without the RFC tag, though.

Feel free to add my

Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>

when you do...

-Toke

  reply	other threads:[~2019-06-03 20:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31  8:10 [PATCH RFC iproute2-next v2] tc: add support for act ctinfo ldir.kdb
2019-06-02  7:33 ` Kevin 'ldir' Darbyshire-Bryant
2019-06-02 18:50 ` [PATCH RFC iproute2-next v3] tc: add support for action act_ctinfo Kevin Darbyshire-Bryant
2019-06-02 20:39   ` Toke Høiland-Jørgensen
2019-06-02 21:55     ` Kevin 'ldir' Darbyshire-Bryant
2019-06-03  9:15       ` Toke Høiland-Jørgensen
2019-06-03 13:50   ` [PATCH RFC iproute2-next v4] " Kevin Darbyshire-Bryant
2019-06-03 20:14     ` Toke Høiland-Jørgensen [this message]
2019-06-05 18:23     ` Joe Perches
2019-06-05 18:54       ` Stephen Hemminger

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=87y32ifmug.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=ldir@darbyshire-bryant.me.uk \
    --cc=netdev@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.