Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S942334AbcJ1RHD (ORCPT ); Fri, 28 Oct 2016 13:07:03 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:35902 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933416AbcJ1RG7 (ORCPT ); Fri, 28 Oct 2016 13:06:59 -0400 Date: Fri, 28 Oct 2016 13:06:57 -0400 (EDT) Message-Id: <20161028.130657.1245186418157500995.davem@davemloft.net> To: alexander.duyck@gmail.com Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, alexander.h.duyck@intel.com, konrad.wilk@oracle.com, jeffrey.t.kirsher@intel.com Subject: Re: [net-next PATCH 00/27] Add support for DMA writable pages being writable by the network stack From: David Miller In-Reply-To: References: <20161025153220.4815.61239.stgit@ahduyck-blue-test.jf.intel.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 28 Oct 2016 10:06:58 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1026 Lines: 23 From: Alexander Duyck Date: Fri, 28 Oct 2016 08:48:01 -0700 > So the feedback for this set has been mostly just a few "Acked-by"s, > and it looks like the series was marked as "Not Applicable" in > patchwork. I was wondering what the correct merge strategy for this > patch set should be going forward? I marked it as not applicable because it's definitely not a networking change, and merging it via my tree would be really inappropriate, even though we need it for some infrastructure we want to build for networking. So you have to merge this upstream via a more appropriate path. > I was wondering if I should be looking at breaking up the set and > splitting it over a few different trees, or if I should just hold onto > it and resubmit it when the merge window opens? My preference would > be to submit it as a single set so I can know all the patches are > present to avoid any possible regressions due to only part of the set > being present. I don't think you need to split it up.