From: Doug Ledford <dledford@redhat.com>
To: Honggang LI <honli@redhat.com>
Cc: Paolo Abeni <pabeni@redhat.com>,
Or Gerlitz <gerlitz.or@gmail.com>,
Erez Shitrit <erezsh@dev.mellanox.co.il>,
Erez Shitrit <erezsh@mellanox.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Linux Netdev List <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH] IB/IPoIB: Check the headroom size
Date: Wed, 26 Apr 2017 09:48:03 -0400 [thread overview]
Message-ID: <1493214483.3041.108.camel@redhat.com> (raw)
In-Reply-To: <20170426133353.GA7898@dhcp-13-42.nay.redhat.com>
On Wed, 2017-04-26 at 21:33 +0800, Honggang LI wrote:
> Yes, it is during the process of removing the final slave. The
> reproducer looks like this:
>
> ping remote_ip_over_bonding_interface &
> while 1; do
> ifdown bond0
> ifup bond0
> done
Honestly, I would suspect the problem here is not when removing the
busy interface, but when bringing the interface back up. IIRC, the
bonding driver defaults to assuming it will be used on an Ethernet
interface. Once you attach an IB slave, it reconfigures itself for
running over IB instead. But once it's configured it should stay
configured until after the last IB slave is removed (and once that
slave it removed, the bond should no longer even possess the pointer to
the ipoib_hard_header routine, so we should never call it).
The process, in the bonding driver, for going down and coming back up
needs to look something like this:
ifdown bond0:
stop all queues
remove all slaves
possibly reconfigure to default state which is Ethernet suitable
ifup bond0:
add first slave
configure for IB instead of Ethernet
start queues
add additional slaves
I'm wondering if, when we have a current backlog, we aren't
accidentally doing this instead:
ifup bond0:
add first slave
release backlog queue
configure for IB instead of Ethernet
add additional slaves
Or, it might even be more subtle, such as:
ifup bond0:
add first slave
configure for IB instead of Ethernet
start queues
-> however, there was a backlog item on the queue from prior to
the first slave being added and the port configured for IB mode,
so the backlog skb is still configured for the default Ethernet
mode, hence the failure
add additional slaves
Maybe the real issue is that inside the bonding driver, when we
reconfigure the queue type from IB to Ethernet or Ethernet to IB, we
need to force either a drop or a reconfiguration of any packets already
currently in our waiting backlog queue of skbs. Paolo?
> >
> > but I don't think it can be after the final slave has been fully
> > removed from the bond. Paolo, what should the bond driver be doing
> > once the slaves are gone? Wouldn't it just be dropping every skb
> > on
> > the floor without calling anyone's hard header routine?
> >
> > >
> > > so it is better to immediately
> > > give up and return error.
> > >
> > > >
> > > >
> > > > + if (ret)
> > > > + return ret;
> > > >
> > > > header = (struct ipoib_header *) skb_push(skb, sizeof
> > > > *header);
> > > > ---
> > > >
> > > > Paolo
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-
> > > > rdma" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.h
> > > > tml
> > --
> > Doug Ledford <dledford@redhat.com>
> > GPG KeyID: B826A3330E572FDD
> >
> > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
> > 2FDD
> >
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
next prev parent reply other threads:[~2017-04-26 13:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-25 9:55 [PATCH] IB/IPoIB: Check the headroom size Honggang LI
[not found] ` <1493114155-12101-1-git-send-email-honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-25 10:11 ` Yuval Shaia
2017-04-25 10:32 ` Or Gerlitz
[not found] ` <CAJ3xEMg4_2ph7QwPsUb-tX-K4d2ppkqz98sPzytsmBCK=29WHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-25 10:57 ` Honggang LI
2017-04-25 11:11 ` Erez Shitrit
[not found] ` <CAAk-MO8O19iC2Yn-BMn5pKTAYxaSzGPMyta=fwes3XSvzmz_cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-25 11:14 ` Or Gerlitz
[not found] ` <CAJ3xEMgw=9sj3rdahPEiST_yDfDJPNSZZLRn43tnb3bK4_RPzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-25 11:43 ` Erez Shitrit
2017-04-25 14:39 ` Or Gerlitz
[not found] ` <CAJ3xEMgwS1Bq8+eZC1iAr6xi8ZPHrchsOJ5r4LNJxR8P+6VipA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-25 15:40 ` Doug Ledford
[not found] ` <1493134815.3041.72.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-25 21:50 ` Or Gerlitz
[not found] ` <CAJ3xEMjqkJrKi+6ronuPBn2P6y8p6sdhVppDzFtMwQrhL13bzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-26 7:46 ` Paolo Abeni
[not found] ` <1493192794.2409.3.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-26 12:52 ` Honggang LI
[not found] ` <20170426125230.GB19179-Y5OA6DF/u0nid9cnFhDO8BcY2uh10dtjAL8bYrjMMd8@public.gmane.org>
2017-04-26 13:25 ` Paolo Abeni
2017-04-26 13:27 ` Doug Ledford
[not found] ` <1493213258.3041.98.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-26 13:33 ` Honggang LI
2017-04-26 13:48 ` Doug Ledford [this message]
[not found] ` <1493214483.3041.108.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-26 13:50 ` Doug Ledford
[not found] ` <1493214638.3041.110.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-26 14:11 ` Honggang LI
[not found] ` <20170426141139.GA14635-Y5OA6DF/u0nid9cnFhDO8BcY2uh10dtjAL8bYrjMMd8@public.gmane.org>
2017-04-26 14:25 ` Doug Ledford
[not found] ` <1493216704.3041.115.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-26 14:44 ` Honggang LI
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=1493214483.3041.108.camel@redhat.com \
--to=dledford@redhat.com \
--cc=davem@davemloft.net \
--cc=erezsh@dev.mellanox.co.il \
--cc=erezsh@mellanox.com \
--cc=gerlitz.or@gmail.com \
--cc=honli@redhat.com \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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).