netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Shannon Nelson <shannon.nelson@oracle.com>
Cc: steffen.klassert@secunet.com, netdev@vger.kernel.org
Subject: Re: [PATCH v3 ipsec-next 3/3] xfrm: wrap xfrmdev_ops with offload config
Date: Wed, 20 Dec 2017 15:20:27 -0200	[thread overview]
Message-ID: <20171220172027.GL6122@localhost.localdomain> (raw)
In-Reply-To: <eba8e3f2-f9f3-fe6a-5bfa-e4532ca478c1@oracle.com>

On Wed, Dec 20, 2017 at 08:22:40AM -0800, Shannon Nelson wrote:
> On 12/20/2017 8:03 AM, Marcelo Ricardo Leitner wrote:
> > On Tue, Dec 19, 2017 at 03:35:49PM -0800, Shannon Nelson wrote:
> > > There's no reason to define netdev->xfrmdev_ops if
> > > the offload facility is not CONFIG'd in.
> > > 
> > > Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
> > 
> > This one could use a Fixes tag perhaps:
> > Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
> > 
> > as in theory the build was broken since then, as it added:
> > +#ifdef CONFIG_XFRM_OFFLOAD
> > +struct xfrmdev_ops {
> > ...
> > +#ifdef CONFIG_XFRM
> > +       const struct xfrmdev_ops *xfrmdev_ops;
> > 
> > So the pointer would have an undefined type
> >    if CONFIG_XFRM && !CONFIG_XFRM_OFFLOAD
> > Though I couldn't reproduce this, not sure why.
> 
> Hmmm, I don't think this requires a "Fixes" tag, as the code all worked just
> fine, I'm just doing a little cleaning.

I still don't get how it works, but okay.

> 
> Patch 2/3 adds a more intense look at the data structure, so I needed to
> change it to the CONFIG_XFRM_OFFLOAD so as to not break the build. Since the
> xfrmdev_ops field is now never used unless we have CONFIG_XFRM_OFFLOAD, we
> can change the net_device definition to be just a bit smaller without it.
> 
> > 
> > But.. is it buildable with this patch? I mine failed:
> > 
> > obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_hash.o \
> >                        xfrm_input.o xfrm_output.o \
> >                        xfrm_sysctl.o xfrm_replay.o xfrm_device.o
> > 
> > so xfrm_device is always in if CONFIG_XFRM is there,
> > xfrm_dev_init(), via xfrm_dev_notifier -> xfrm_dev_event() ->
> >    xfrm_dev_register() and then:
> > 
> > static int xfrm_dev_register(struct net_device *dev)
> > {
> >          if ((dev->features & NETIF_F_HW_ESP) && !dev->xfrmdev_ops)
> 
> This looks like you haven't applied version 3 of the 2nd patch "xfrm: check
> for xdo_dev_ops add and delete".  I missed this in the earlier version (not
> enough compile tests), but version 3 of patch 2/3  should address it.

Right you are, missed it here.

Thanks,
Marcelo

  reply	other threads:[~2017-12-20 17:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-19 23:35 [PATCH v3 ipsec-next 0/3] xfrm: offload api fixes Shannon Nelson
2017-12-19 23:35 ` [PATCH v3 ipsec-next 1/3] xfrm: check for xdo_dev_state_free Shannon Nelson
2017-12-19 23:35 ` [PATCH v3 ipsec-next 2/3] xfrm: check for xdo_dev_ops add and delete Shannon Nelson
2017-12-19 23:35 ` [PATCH v3 ipsec-next 3/3] xfrm: wrap xfrmdev_ops with offload config Shannon Nelson
2017-12-20 16:03   ` Marcelo Ricardo Leitner
2017-12-20 16:22     ` Shannon Nelson
2017-12-20 17:20       ` Marcelo Ricardo Leitner [this message]
2017-12-21 10:35 ` [PATCH v3 ipsec-next 0/3] xfrm: offload api fixes Steffen Klassert

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=20171220172027.GL6122@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=shannon.nelson@oracle.com \
    --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 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).