On Tue, Aug 15, 2017 at 09:03:58PM -0700, David Miller wrote:
> From: David Miller
> Date: Tue, 15 Aug 2017 17:52:40 -0700 (PDT)
>
> > From: Simon Horman
> > Date: Tue, 15 Aug 2017 08:13:48 +0200
> >
> >> Could you pull net into net-next? I'd like to send up a follow-up
> >> for net-next to all
From: David Miller
Date: Tue, 15 Aug 2017 17:52:40 -0700 (PDT)
> From: Simon Horman
> Date: Tue, 15 Aug 2017 08:13:48 +0200
>
>> Could you pull net into net-next? I'd like to send up a follow-up
>> for net-next to allow processing of the MTU.
>
> Once Linus takes the pull request I just sent t
From: Simon Horman
Date: Tue, 15 Aug 2017 08:13:48 +0200
> Could you pull net into net-next? I'd like to send up a follow-up
> for net-next to allow processing of the MTU.
Once Linus takes the pull request I just sent to him, I will
do this.
On Fri, Aug 11, 2017 at 02:51:07PM -0700, David Miller wrote:
> From: Simon Horman
> Date: Fri, 11 Aug 2017 10:18:20 +0200
>
> > The Flower app may receive a request to update the MTU of a representor
> > netdev upon receipt of a control message from the firmware. This requires
> > the RTNL lock
From: Simon Horman
Date: Fri, 11 Aug 2017 10:18:20 +0200
> The Flower app may receive a request to update the MTU of a representor
> netdev upon receipt of a control message from the firmware. This requires
> the RTNL lock which needs to be taken outside of the packet processing
> path.
>
> As a
The Flower app may receive a request to update the MTU of a representor
netdev upon receipt of a control message from the firmware. This requires
the RTNL lock which needs to be taken outside of the packet processing
path.
As a handling of this correctly seems a little to invasive for a fix simply
