All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Andy Shevchenko <andy@kernel.org>
Cc: Marcin Szycik <marcin.szycik@linux.intel.com>,
	<intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
	<wojciech.drewek@intel.com>, <michal.swiatkowski@linux.intel.com>,
	<davem@davemloft.net>, <kuba@kernel.org>, <jiri@resnulli.us>,
	<pabeni@redhat.com>, <jesse.brandeburg@intel.com>,
	<simon.horman@corigine.com>, <idosch@nvidia.com>
Subject: Re: [PATCH iwl-next v3 1/6] ip_tunnel: use a separate struct to store tunnel params in the kernel
Date: Mon, 24 Jul 2023 16:21:52 +0200	[thread overview]
Message-ID: <42a51ef3-9fa7-36e6-77c6-475ad795df3a@intel.com> (raw)
In-Reply-To: <ZLqUfwKkRH85uPlT@smile.fi.intel.com>

From: Andy Shevchenko <andy@kernel.org>
Date: Fri, 21 Jul 2023 17:21:51 +0300

> On Fri, Jul 21, 2023 at 09:15:27AM +0200, Marcin Szycik wrote:
>> From: Alexander Lobakin <aleksander.lobakin@intel.com>
>>
>> Unlike IPv6 tunnels which use purely-kernel __ip6_tnl_parm structure
>> to store params inside the kernel, IPv4 tunnel code uses the same
>> ip_tunnel_parm which is being used to talk with the userspace.
>> This makes it difficult to alter or add any fields or use a
>> different format for whatever data.
>> Define struct ip_tunnel_parm_kern, a 1:1 copy of ip_tunnel_parm for
>> now, and use it throughout the code. The two places where the latter
>> is used to interact with the userspace, now do a conversion from one
>> type to another, with manual field-by-field assignments.
>> Must be done at once, since ip_tunnel::parms is being used in most
>> of those places.
> 
> ...
> 
>> +	strscpy(kp.name, p.name, sizeof(kp.name));
>> +	kp.link = p.link;
>> +	kp.i_flags = p.i_flags;
>> +	kp.o_flags = p.o_flags;
>> +	kp.i_key = p.i_key;
>> +	kp.o_key = p.o_key;
>> +	memcpy(&kp.iph, &p.iph, min(sizeof(kp.iph), sizeof(p.iph)));
>> +
>> +	err = dev->netdev_ops->ndo_tunnel_ctl(dev, &kp, cmd);
>> +	if (err)
>> +		return err;
>> +
>> +	strscpy(p.name, kp.name, sizeof(p.name));
>> +	p.link = kp.link;
>> +	p.i_flags = kp.i_flags;
>> +	p.o_flags = kp.o_flags;
>> +	p.i_key = kp.i_key;
>> +	p.o_key = kp.o_key;
>> +	memcpy(&p.iph, &kp.iph, min(sizeof(p.iph), sizeof(kp.iph)));
> 
>> +		strscpy(kp.name, p.name, sizeof(kp.name));
>> +		kp.link = p.link;
>> +		kp.i_flags = p.i_flags;
>> +		kp.o_flags = p.o_flags;
>> +		kp.i_key = p.i_key;
>> +		kp.o_key = p.o_key;
>> +		memcpy(&kp.iph, &p.iph, min(sizeof(p.iph), sizeof(kp.iph)));
> 
> Seems to me these two deserves separate helpers to avoid such a duplication(s).
> 

Sounds reasonable, thanks!

Olek

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Andy Shevchenko <andy@kernel.org>
Cc: jiri@resnulli.us, netdev@vger.kernel.org, idosch@nvidia.com,
	jesse.brandeburg@intel.com, intel-wired-lan@lists.osuosl.org,
	kuba@kernel.org, simon.horman@corigine.com, pabeni@redhat.com,
	davem@davemloft.net
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3 1/6] ip_tunnel: use a separate struct to store tunnel params in the kernel
Date: Mon, 24 Jul 2023 16:21:52 +0200	[thread overview]
Message-ID: <42a51ef3-9fa7-36e6-77c6-475ad795df3a@intel.com> (raw)
In-Reply-To: <ZLqUfwKkRH85uPlT@smile.fi.intel.com>

From: Andy Shevchenko <andy@kernel.org>
Date: Fri, 21 Jul 2023 17:21:51 +0300

> On Fri, Jul 21, 2023 at 09:15:27AM +0200, Marcin Szycik wrote:
>> From: Alexander Lobakin <aleksander.lobakin@intel.com>
>>
>> Unlike IPv6 tunnels which use purely-kernel __ip6_tnl_parm structure
>> to store params inside the kernel, IPv4 tunnel code uses the same
>> ip_tunnel_parm which is being used to talk with the userspace.
>> This makes it difficult to alter or add any fields or use a
>> different format for whatever data.
>> Define struct ip_tunnel_parm_kern, a 1:1 copy of ip_tunnel_parm for
>> now, and use it throughout the code. The two places where the latter
>> is used to interact with the userspace, now do a conversion from one
>> type to another, with manual field-by-field assignments.
>> Must be done at once, since ip_tunnel::parms is being used in most
>> of those places.
> 
> ...
> 
>> +	strscpy(kp.name, p.name, sizeof(kp.name));
>> +	kp.link = p.link;
>> +	kp.i_flags = p.i_flags;
>> +	kp.o_flags = p.o_flags;
>> +	kp.i_key = p.i_key;
>> +	kp.o_key = p.o_key;
>> +	memcpy(&kp.iph, &p.iph, min(sizeof(kp.iph), sizeof(p.iph)));
>> +
>> +	err = dev->netdev_ops->ndo_tunnel_ctl(dev, &kp, cmd);
>> +	if (err)
>> +		return err;
>> +
>> +	strscpy(p.name, kp.name, sizeof(p.name));
>> +	p.link = kp.link;
>> +	p.i_flags = kp.i_flags;
>> +	p.o_flags = kp.o_flags;
>> +	p.i_key = kp.i_key;
>> +	p.o_key = kp.o_key;
>> +	memcpy(&p.iph, &kp.iph, min(sizeof(p.iph), sizeof(kp.iph)));
> 
>> +		strscpy(kp.name, p.name, sizeof(kp.name));
>> +		kp.link = p.link;
>> +		kp.i_flags = p.i_flags;
>> +		kp.o_flags = p.o_flags;
>> +		kp.i_key = p.i_key;
>> +		kp.o_key = p.o_key;
>> +		memcpy(&kp.iph, &p.iph, min(sizeof(p.iph), sizeof(kp.iph)));
> 
> Seems to me these two deserves separate helpers to avoid such a duplication(s).
> 

Sounds reasonable, thanks!

Olek
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2023-07-24 14:23 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21  7:15 [PATCH iwl-next v3 0/6] ice: Add PFCP filter support Marcin Szycik
2023-07-21  7:15 ` [Intel-wired-lan] " Marcin Szycik
2023-07-21  7:15 ` [PATCH iwl-next v3 1/6] ip_tunnel: use a separate struct to store tunnel params in the kernel Marcin Szycik
2023-07-21  7:15   ` [Intel-wired-lan] " Marcin Szycik
2023-07-21 14:21   ` Andy Shevchenko
2023-07-21 14:21     ` [Intel-wired-lan] " Andy Shevchenko
2023-07-24 14:21     ` Alexander Lobakin [this message]
2023-07-24 14:21       ` Alexander Lobakin
2023-07-21  7:15 ` [PATCH iwl-next v3 2/6] ip_tunnel: convert __be16 tunnel flags to bitmaps Marcin Szycik
2023-07-21  7:15   ` [Intel-wired-lan] " Marcin Szycik
     [not found]   ` <ZLqZRFa1VOHHWCqX@smile.fi.intel.com>
2023-07-26 11:09     ` Alexander Lobakin
2023-07-26 11:09       ` Alexander Lobakin
2023-07-26 12:01       ` [Intel-wired-lan] " Andy Shevchenko
2023-07-26 12:01         ` Andy Shevchenko
2023-07-26 12:05         ` Andy Shevchenko
2023-07-26 12:05           ` [Intel-wired-lan] " Andy Shevchenko
2023-07-26 13:16         ` Alexander Lobakin
2023-07-26 13:16           ` Alexander Lobakin
2023-07-26 14:32           ` Andy Shevchenko
2023-07-26 14:32             ` [Intel-wired-lan] " Andy Shevchenko
2023-07-21  7:15 ` [PATCH iwl-next v3 3/6] pfcp: add PFCP module Marcin Szycik
2023-07-21  7:15   ` [Intel-wired-lan] " Marcin Szycik
2023-07-21 14:54   ` Andy Shevchenko
2023-07-21 14:54     ` [Intel-wired-lan] " Andy Shevchenko
2023-07-24 10:36     ` Marcin Szycik
2023-07-24 10:36       ` Marcin Szycik
2023-07-21  7:15 ` [PATCH iwl-next v3 4/6] pfcp: always set pfcp metadata Marcin Szycik
2023-07-21  7:15   ` [Intel-wired-lan] " Marcin Szycik
2023-07-21 15:02   ` Andy Shevchenko
2023-07-21 15:02     ` [Intel-wired-lan] " Andy Shevchenko
2023-07-24 13:19     ` Marcin Szycik
2023-07-24 13:19       ` [Intel-wired-lan] " Marcin Szycik
2023-07-21  7:15 ` [PATCH iwl-next v3 5/6] ice: refactor ICE_TC_FLWR_FIELD_ENC_OPTS Marcin Szycik
2023-07-21  7:15   ` [Intel-wired-lan] " Marcin Szycik
2023-07-21  7:15 ` [PATCH iwl-next v3 6/6] ice: Add support for PFCP hardware offload in switchdev Marcin Szycik
2023-07-21  7:15   ` [Intel-wired-lan] " Marcin Szycik
2023-07-21 15:07   ` Andy Shevchenko
2023-07-21 15:07     ` [Intel-wired-lan] " Andy Shevchenko
2023-07-24 13:58     ` Marcin Szycik
2023-07-24 13:58       ` [Intel-wired-lan] " Marcin Szycik
2023-07-24 14:10       ` Andy Shevchenko
2023-07-24 14:10         ` [Intel-wired-lan] " Andy Shevchenko

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=42a51ef3-9fa7-36e6-77c6-475ad795df3a@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=andy@kernel.org \
    --cc=davem@davemloft.net \
    --cc=idosch@nvidia.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=marcin.szycik@linux.intel.com \
    --cc=michal.swiatkowski@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=simon.horman@corigine.com \
    --cc=wojciech.drewek@intel.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.