From: Davide Caratti <dcaratti@redhat.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
David Laight <David.Laight@aculab.com>,
"David S . Miller" <davem@davemloft.net>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
"linux-sctp @ vger . kernel . org" <linux-sctp@vger.kernel.org>
Subject: Re: [PATCH RFC net-next v3 4/7] net: use skb->csum_algo to identify packets needing crc32c
Date: Fri, 07 Apr 2017 17:29:20 +0000 [thread overview]
Message-ID: <1491586160.2505.87.camel@redhat.com> (raw)
In-Reply-To: <CALx6S34DdGZo7e1e37UCtpZ48jgdvHJ5nR=keyGFq3O3-b2_YQ@mail.gmail.com>
hello Tom,
On Fri, 2017-04-07 at 08:43 -0700, Tom Herbert wrote:
> On Fri, Apr 7, 2017 at 7:16 AM, Davide Caratti <dcaratti@redhat.com> wrote:
> > @@ -742,8 +744,10 @@ struct sk_buff {
> > __u8 csum_valid:1;
> > __u8 csum_complete_sw:1;
> > __u8 csum_level:2;
> > - __u8 __unused:1; /* one bit hole */
> > -
> > + enum {
> > + INTERNET_CHECKSUM = 0,
> > + CRC32C_CHECKSUM,
> > + } csum_algo:1;
>
> I am worried this opens the door to a new open ended functionality
> that will be rarely used in practice. Checksum offload is pervasive,
> CRC offload is still a very narrow use case.
thank you for the prompt response. I thought there was a silent
agreement on that - Alexander proposed usage of an enum bitfield to be
ready for FCoE (and I'm not against it, unless I have to find a second
free bit in struct sk_buff :-) ). But maybe I'm misunderstanding your
concern: is it the name of the variable, (csum_algo instead of
crc32c_csum), or the usage of enum bitfield (or both?) ?
On Fri, 2017-04-07 at 08:43 -0700, Tom Herbert wrote:
> Adding yet more
> CRC/checksum variants will need more bits. It may be sufficient for
> now just to make this a single bit which indicates "ones' checksum" or
> indicates "other". In this case of "other" we need some analysis so
> determine which checksum it is, this might be something that flow
> dissector could support.
... which is my intent: by the way, from my perspective, we don't need more than 1 bit
to extend the functionality. While reviewing my code, I was also considering
extending the witdth of skb->ip_summed from 2 to 3 bit, so that it was possible
to
#define
CRC32C_PARTIAL <- for SCTP
CRC_PARTIAL <- for FCoE
CHECKSUM_PARTIAL <- for everything else
It's conceptually the same thing, and the free bit is used more
efficiently. But then I would need to check all places where
CHECKSUM_PARTIAL is used in assignments and test: so, I told myself it's
not worth doing it until somebody requests to extend this functionality to
FCoE.
> > @@ -3129,6 +3133,14 @@ struct skb_checksum_ops {
> >
> > extern const struct skb_checksum_ops *crc32c_csum_stub __read_mostly;
> >
> > +static inline void skb_set_crc32c_ipsummed(struct sk_buff *skb,
> > + const u8 ip_summed)
> > +{
> > + skb->csum_algo = ip_summed = CHECKSUM_PARTIAL ? CRC32C_CHECKSUM :
> > + INTERNET_CHECKSUM;
> > + skb->ip_summed = ip_summed;
>
> This seems odd to me. skb->csum_algo and skb->ip_summed always end up
> having the same value.
this is accidentally true for CHEKSUM_NONE and CHECKSUM_PARTIAL, and only
if skb carries a SCTP packet. This was my intent:
ip_summed (2 bit) | csum_algo (1 bit)
---------------------------------------+-------------------
CHEKSUM_NONE = 0 | INTERNET_CHECKSUM = 0
CHECKSUM_PARTIAL = 1 | CRC32C_CHECKSUM = 1
CHECKSUM_COMPLETE = 2 (not applicable) | INTERNET_CHECKSUM = 0 (don't care)
CHECKSUM_UNNECESSARY = 3 | INTERNET_CHECKSUM = 0
I can do this in a more explicit way, changing the prototype to
static inline void skb_set_crc32c_ipsummed(struct sk_buff *skb,
const u8 ip_summed,
const u8 csum_algo)
(with the advantage of saving a test on the value of ip_summed).
Find in the comment below the reason why I'm clearing csum_algo every time
the SCTP CRC32c is computed.
> > --- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> > +++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> > @@ -81,7 +81,7 @@ static void sctp_nat_csum(struct sk_buff *skb, sctp_sctphdr_t *sctph,
> > unsigned int sctphoff)
> > {
> > sctph->checksum = sctp_compute_cksum(skb, sctphoff);
> > - skb->ip_summed = CHECKSUM_UNNECESSARY;
> > + skb_set_crc32c_ipsummed(skb, CHECKSUM_UNNECESSARY);
>
> The old code is better. CHECKSUM_UNNECESSARY already applies to non IP
> checksums. There is nothing special about crc32 in this regard and
> skb->csum_algo should only be valid when skb->ip_summed =
> CHECKSUM_PARTIAL so no need to set it here. This point should also be
> in documentation.
In my understanding, csum_algo needs to be set to INTERNET_CHECKSUM after the
CRC32c is computed. Otherwise, after subsequent operation on the skb (e.g. it
is encapsulated in a UDP frame), there is the possibility for skb->ip_summed
to become CHECKSUM_PARTIAL again. So, to ensure that skb_checksum_help() and
not skb_crc32c_help() will be called, csum_algo must be 0.
To minimize the impact of the patch, I substituted all assignments of skb->ip_summed,
done by SCTP-related code, with calls to skb_set_crc32c_ipsummed(). The alternative is
to explicitly set csum_algo to 0 (INTERNET_CHECKSUM) in SCTP-related code. Do you agree?
thank you in advance,
regards
--
davide
next prev parent reply other threads:[~2017-04-07 17:29 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-23 16:52 [RFC PATCH net-next 0/5] net: improve support for SCTP checksums Davide Caratti
2017-01-23 16:52 ` [RFC PATCH net-next 1/5] skbuff: add stub to help computing crc32c on SCTP packets Davide Caratti
2017-01-23 16:52 ` [RFC PATCH net-next 2/5] net: split skb_checksum_help Davide Caratti
2017-01-23 20:59 ` Tom Herbert
2017-01-24 16:35 ` David Laight
2017-02-02 15:07 ` Davide Caratti
2017-02-02 16:55 ` David Laight
2017-02-02 18:08 ` Tom Herbert
2017-02-27 13:39 ` Davide Caratti
2017-02-27 15:11 ` Tom Herbert
2017-02-28 10:31 ` Davide Caratti
2017-02-28 10:32 ` [PATCH RFC net-next v2 1/4] skbuff: add stub to help computing crc32c on SCTP packets Davide Caratti
2017-02-28 22:46 ` Alexander Duyck
2017-03-01 3:17 ` Tom Herbert
2017-03-01 10:53 ` David Laight
2017-03-06 21:51 ` Davide Caratti
2017-03-07 18:06 ` Alexander Duyck
2017-03-18 13:17 ` Davide Caratti
2017-03-18 22:35 ` Tom Herbert
2017-04-07 14:16 ` [PATCH RFC net-next v3 0/7] improve CRC32c in the forwarding path Davide Caratti
2017-04-07 14:16 ` [PATCH RFC net-next v3 1/7] skbuff: add stub to help computing crc32c on SCTP packets Davide Caratti
2017-04-07 14:16 ` [PATCH RFC net-next v3 2/7] net: introduce skb_crc32c_csum_help Davide Caratti
2017-04-07 14:16 ` [PATCH RFC net-next v3 3/7] sk_buff: remove support for csum_bad in sk_buff Davide Caratti
2017-04-07 14:16 ` [PATCH RFC net-next v3 4/7] net: use skb->csum_algo to identify packets needing crc32c Davide Caratti
2017-04-07 15:43 ` Tom Herbert
2017-04-07 17:29 ` Davide Caratti [this message]
2017-04-07 18:11 ` Tom Herbert
2017-04-13 10:36 ` Davide Caratti
2017-04-20 13:38 ` [PATCH RFC net-next v4 0/7] net: improve support for SCTP checksums Davide Caratti
2017-04-27 12:41 ` Marcelo Ricardo Leitner
2017-04-20 13:38 ` [PATCH RFC net-next v4 1/7] skbuff: add stub to help computing crc32c on SCTP packets Davide Caratti
2017-04-20 13:38 ` [PATCH RFC net-next v4 2/7] net: introduce skb_crc32c_csum_help Davide Caratti
2017-04-27 12:29 ` Marcelo Ricardo Leitner
2017-04-20 13:38 ` [PATCH RFC net-next v4 3/7] sk_buff: remove support for csum_bad in sk_buff Davide Caratti
2017-04-29 20:21 ` Tom Herbert
2017-04-20 13:38 ` [PATCH RFC net-next v4 4/7] net: use skb->csum_not_inet to identify packets needing crc32c Davide Caratti
2017-04-29 20:18 ` Tom Herbert
2017-04-20 13:38 ` [PATCH RFC net-next v4 5/7] net: more accurate checksumming in validate_xmit_skb() Davide Caratti
2017-04-20 13:38 ` [PATCH RFC net-next v4 6/7] openvswitch: more accurate checksumming in queue_userspace_packet() Davide Caratti
2017-04-20 13:38 ` [PATCH RFC net-next v4 7/7] sk_buff.h: improve description of CHECKSUM_{COMPLETE,UNNECESSARY} Davide Caratti
2017-04-29 20:20 ` Tom Herbert
2017-04-07 14:16 ` [PATCH RFC net-next v3 5/7] net: more accurate checksumming in validate_xmit_skb() Davide Caratti
2017-04-07 14:16 ` [PATCH RFC net-next v3 6/7] openvswitch: more accurate checksumming in queue_userspace_packet() Davide Caratti
2017-04-07 14:16 ` [PATCH RFC net-next v3 7/7] sk_buff.h: improve description of CHECKSUM_{COMPLETE,UNNECESSARY} Davide Caratti
2017-02-28 10:32 ` [PATCH RFC net-next v2 2/4] net: introduce skb_sctp_csum_help Davide Caratti
2017-02-28 10:32 ` [PATCH RFC net-next v2 3/4] net: more accurate checksumming in validate_xmit_skb Davide Caratti
2017-02-28 19:50 ` Tom Herbert
2017-02-28 10:32 ` [PATCH RFC net-next v2 4/4] Documentation: update notes on checksum offloading Davide Caratti
2017-01-23 16:52 ` [RFC PATCH net-next 3/5] net: introduce skb_sctp_csum_help Davide Caratti
2017-01-23 16:52 ` [RFC PATCH net-next 4/5] net: more accurate checksumming in validate_xmit_skb Davide Caratti
2017-01-23 16:52 ` [RFC PATCH net-next 5/5] Documentation: add description of skb_sctp_csum_help Davide Caratti
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=1491586160.2505.87.camel@redhat.com \
--to=dcaratti@redhat.com \
--cc=David.Laight@aculab.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.com \
/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).