From: Christian Hopps <chopps@chopps.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: Christian Hopps <chopps@chopps.org>,
devel@linux-ipsec.org,
Steffen Klassert <steffen.klassert@secunet.com>,
netdev@vger.kernel.org, Christian Hopps <chopps@labn.net>
Subject: Re: [RFC ipsec-next v2 2/8] iptfs: uapi: ip: add ip_tfs_*_hdr packet formats
Date: Thu, 01 Feb 2024 09:15:33 -0500 [thread overview]
Message-ID: <m2cytg6zfr.fsf@ja.int.chopps.org> (raw)
In-Reply-To: <ZVt7Nud5U5FbUJ3f@hog>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
Sabrina Dubroca <sd@queasysnail.net> writes:
> 2023-11-12, 22:52:13 -0500, Christian Hopps wrote:
>> From: Christian Hopps <chopps@labn.net>
>>
>> Add the on-wire basic and congestion-control IP-TFS packet headers.
>>
>> Signed-off-by: Christian Hopps <chopps@labn.net>
>> ---
>> include/uapi/linux/ip.h | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/include/uapi/linux/ip.h b/include/uapi/linux/ip.h
>> index 283dec7e3645..cc83878ecf08 100644
>> --- a/include/uapi/linux/ip.h
>> +++ b/include/uapi/linux/ip.h
>> @@ -137,6 +137,23 @@ struct ip_beet_phdr {
>> __u8 reserved;
>> };
>>
>> +struct ip_iptfs_hdr {
>> + __u8 subtype; /* 0*: basic, 1: CC */
>> + __u8 flags;
>> + __be16 block_offset;
>> +};
>> +
>> +struct ip_iptfs_cc_hdr {
>> + __u8 subtype; /* 0: basic, 1*: CC */
>> + __u8 flags;
>> + __be16 block_offset;
>> + __be32 loss_rate;
>> + __u8 rtt_and_adelay1[4];
>> + __u8 adelay2_and_xdelay[4];
>
> Given how the fields are split, wouldn't it be more convenient to have
> a single __be64, rather than reading some bits from multiple __u8?
Changed this to __be64.
>> + __be32 tval;
>> + __be32 techo;
>> +};
>
> I don't think these need to be part of uapi. Can we move them to
> include/net/iptfs.h (or possibly net/xfrm/xfrm_iptfs.c)? It would also
> make more sense to have them near the definitions for
> IPTFS_SUBTYPE_*. And it would be easier to change how we split and
> name fields for kernel consumption if we're not stuck with whatever we
> put in uapi.
I saw this also as the place documenting the packet format. Userland can have raw packets delivered to them... Mostly though I was following the pattern that existed already.
Thanks,
Chris.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
next prev parent reply other threads:[~2024-02-01 14:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 3:52 [RFC ipsec-next v2 0/8] Add IP-TFS mode to xfrm Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 1/8] iptfs: config: add CONFIG_XFRM_IPTFS Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 2/8] iptfs: uapi: ip: add ip_tfs_*_hdr packet formats Christian Hopps
2023-11-20 15:28 ` Sabrina Dubroca
2023-11-20 20:18 ` Christian Hopps
2023-11-20 22:38 ` Sabrina Dubroca
2024-02-01 14:15 ` Christian Hopps [this message]
2023-11-13 3:52 ` [RFC ipsec-next v2 3/8] iptfs: uapi: IPPROTO_AGGFRAG AGGFRAG in ESP Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 4/8] iptfs: sysctl: allow configuration of global default values Christian Hopps
2023-11-20 23:05 ` Sabrina Dubroca
2024-02-01 13:57 ` Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 5/8] iptfs: netlink: add config (netlink) options Christian Hopps
2023-11-30 15:36 ` Sabrina Dubroca
2023-11-13 3:52 ` [RFC ipsec-next v2 6/8] iptfs: xfrm: Add mode_cbs module functionality Christian Hopps
2023-11-13 14:07 ` [devel-ipsec] " Antony Antony
2023-11-15 19:04 ` Antony Antony
2023-11-30 15:35 ` Sabrina Dubroca
2024-02-01 15:34 ` Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 7/8] iptfs: xfrm: add generic iptfs defines and functionality Christian Hopps
2023-11-13 3:52 ` [RFC ipsec-next v2 8/8] iptfs: impl: add new iptfs xfrm mode impl Christian Hopps
2023-11-13 10:05 ` kernel test robot
2023-11-30 15:33 ` Sabrina Dubroca
2024-02-02 9:44 ` Christian Hopps
2023-11-13 7:15 ` [RFC ipsec-next v2 0/8] Add IP-TFS mode to xfrm Steffen Klassert
2023-11-16 15:14 ` [devel-ipsec] " Andrew Cagney
2023-11-20 18:39 ` Christian Hopps
2023-11-20 20:00 ` [DKIM] " Antony Antony
2023-11-20 20:02 ` Antony Antony
2023-11-20 20:14 ` Christian Hopps
2023-11-21 19:13 ` Antony Antony
2023-11-16 16:02 ` Antony Antony
2024-03-07 11:05 ` Christian Hopps
2024-03-10 20:34 ` Antony Antony
2023-11-28 22:12 ` Antony Antony
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=m2cytg6zfr.fsf@ja.int.chopps.org \
--to=chopps@chopps.org \
--cc=chopps@labn.net \
--cc=devel@linux-ipsec.org \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
--cc=steffen.klassert@secunet.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 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.