* Re: [PATCH net-next] net: remove netdevice gso_min_segs
From: David Miller @ 2016-04-14 4:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1460226598.6473.518.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 09 Apr 2016 11:29:58 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> After introduction of ndo_features_check(), we believe that very
> specific checks for rare features should not be done in core
> networking stack.
>
> No driver uses gso_min_segs yet, so we revert this feature and save
> few instructions per tx packet in fast path.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] qdisc: constify meta_type_ops structures
From: David Miller @ 2016-04-14 4:35 UTC (permalink / raw)
To: Julia.Lawall; +Cc: jhs, kernel-janitors, netdev, linux-kernel
In-Reply-To: <1460191762-10986-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sat, 9 Apr 2016 10:49:22 +0200
> The meta_type_ops structures are never modified, so declare them as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2] net: bcmgenet: add BQL support
From: David Miller @ 2016-04-14 4:34 UTC (permalink / raw)
To: pgynther; +Cc: netdev, eric.dumazet, f.fainelli, opendmb, jaedon.shin
In-Reply-To: <1460186436-84848-1-git-send-email-pgynther@google.com>
From: Petri Gynther <pgynther@google.com>
Date: Sat, 9 Apr 2016 00:20:36 -0700
> Add Byte Queue Limits (BQL) support to bcmgenet driver.
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
Applied, thank you.
^ permalink raw reply
* Re: [net 0/2][pull request] Intel Wired LAN Driver Updates 2016-04-13
From: David Miller @ 2016-04-14 4:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <1460605632-112945-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 13 Apr 2016 20:47:10 -0700
> This series contains updates to i40e, i40evf and fm10k.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: David Miller @ 2016-04-14 4:19 UTC (permalink / raw)
To: roopa; +Cc: netdev, jhs
In-Reply-To: <1460183892-57286-2-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Fri, 8 Apr 2016 23:38:11 -0700
> This patch adds a new RTM_GETSTATS message to query link stats via netlink
> from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
> returns a lot more than just stats and is expensive in some cases when
> frequent polling for stats from userspace is a common operation.
Great work. One thing catches my eye:
> + if (filter_mask & IFLA_STATS_FILTER_BIT(IFLA_STATS_LINK64)) {
> + attr = nla_reserve(skb, IFLA_STATS_LINK64,
> + sizeof(struct rtnl_link_stats64));
> + if (!attr)
> + return -EMSGSIZE;
> +
> + stats = dev_get_stats(dev, &temp);
> +
> + copy_rtnl_link_stats64(nla_data(attr), stats);
This extra copy bothers me, so I tried to figure out what is going
on here.
dev_get_stats() always returns the rtnl_link_stats64 pointer it was
given. We should be able to pass, therefore, nla_data(attr), straight
there to avoid the copy.
Bonding even uses dev_get_stats() in this way.
The existing rtnl_fill_stats() can be improved similarly but is of
course a separate change. In that case, we'd do something like:
struct rtnl_link_stats64 *sp;
attr = nla_reserve(skb, IFLA_STATS64,
sizeof(struct rtnl_link_stats64));
if (!attr)
return -EMSGSIZE;
sp = nla_data(attr);
dev_get_stats(dev, sp);
attr = nla_reserve(skb, IFLA_STATS,
sizeof(struct rtnl_link_stats));
if (!attr)
return -EMSGSIZE;
copy_rtnl_link_stats(nla_data(attr), sp);
Thanks.
^ permalink raw reply
* [PATCH V3 00/29] bitops: add parity functions
From: zengzhaoxiu @ 2016-04-14 4:18 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald,
linux-alpha, linux-snps-arc, linux-arm-kernel,
adi-buildroot-devel, linux-c6x-dev, linux-cris-kernel,
uclinux-h8-devel, linux-hexagon, linux-ia64, linux-m68k,
linux-metag, linux-mips, linux-am33-list, linux, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, linux-xtensa,
qat-linux
In-Reply-To: <1460601525-3822-1-git-send-email-zengzhaoxiu@163.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
When I do "grep parity -r linux", I found many parity calculations
distributed in many drivers.
This patch series does:
1. provide generic and architecture-specific parity calculations
2. remove drivers' local parity calculations, use bitops' parity
functions instead
3. replace "hweightN(x) & 1" with "parityN(x)" to improve readability,
and improve performance on some CPUs that without popcount support
I did not use GCC's __builtin_parity* functions, based on the following reasons:
1. I don't know where to identify which version of GCC from the beginning
supported __builtin_parity for the architecture.
2. For the architecture that doesn't has popcount instruction, GCC instead use
"call __paritysi2" (__paritydi2 for 64-bits). So if use __builtin_parity, we must
provide __paritysi2 and __paritydi2 functions for these architectures.
Additionally, parity4,8,16 might be "__builtin_parity(x & mask)", but the "& mask"
operation is totally unnecessary.
3. For the architecture that has popcount instruction, we do the same things.
4. For powerpc, sparc, and x86, we do runtime patching to use popcount instruction
if the CPU support.
I have compiled successfully with x86_64_defconfig, i386_defconfig, pseries_defconfig
and sparc64_defconfig.
Changes to v2:
- Add constant PARITY_MAGIC (proposals by Sam Ravnborg)
- Add include/asm-generic/bitops/popc-parity.h (proposals by Chris Metcalf)
- Tile uses popc-parity.h directly
- Mips uses popc-parity.h if has usable __builtin_popcount
- Add few comments in powerpc's and sparc's parity.S
- X86, remove custom calling convention
Changes to v1:
- Add runtime patching for powerpc, sparc, and x86
- Avr32 use grenric parity too
- Fix error in ssfdc's patch, and add commit message
- Don't change the original code composition of drivers/iio/gyro/adxrs450.c
- Directly assignement to phy_cap.parity in drivers/scsi/isci/phy.c
Regards,
=== diffstat ===
Zhaoxiu Zeng (29):
bitops: add parity functions
Include generic parity.h in some architectures' bitops.h
Add alpha-specific parity functions
Add blackfin-specific parity functions
Add ia64-specific parity functions
Tile and MIPS (if has usable __builtin_popcount) use popcount parity
functions
Add powerpc-specific parity functions
Add sparc-specific parity functions
Add x86-specific parity functions
sunrpc: use parity8
mips: use parity functions in cerr-sb1.c
bch: use parity32
media: use parity8 in vivid-vbi-gen.c
media: use parity functions in saa7115
input: use parity32 in grip_mp
input: use parity64 in sidewinder
input: use parity16 in ams_delta_serio
scsi: use parity32 in isci's phy
mtd: use parity16 in ssfdc
mtd: use parity functions in inftlcore
crypto: use parity functions in qat_hal
mtd: use parity16 in sm_ftl
ethernet: use parity8 in sun/niu.c
input: use parity8 in pcips2
input: use parity8 in sa1111ps2
iio: use parity32 in adxrs450
serial: use parity32 in max3100
input: use parity8 in elantech
ethernet: use parity8 in broadcom/tg3.c
arch/alpha/include/asm/bitops.h | 27 +++++
arch/arc/include/asm/bitops.h | 1 +
arch/arm/include/asm/bitops.h | 1 +
arch/arm64/include/asm/bitops.h | 1 +
arch/avr32/include/asm/bitops.h | 1 +
arch/blackfin/include/asm/bitops.h | 31 ++++++
arch/c6x/include/asm/bitops.h | 1 +
arch/cris/include/asm/bitops.h | 1 +
arch/frv/include/asm/bitops.h | 1 +
arch/h8300/include/asm/bitops.h | 1 +
arch/hexagon/include/asm/bitops.h | 1 +
arch/ia64/include/asm/bitops.h | 31 ++++++
arch/m32r/include/asm/bitops.h | 1 +
arch/m68k/include/asm/bitops.h | 1 +
arch/metag/include/asm/bitops.h | 1 +
arch/mips/include/asm/bitops.h | 7 ++
arch/mips/mm/cerr-sb1.c | 67 ++++---------
arch/mn10300/include/asm/bitops.h | 1 +
arch/openrisc/include/asm/bitops.h | 1 +
arch/parisc/include/asm/bitops.h | 1 +
arch/powerpc/include/asm/bitops.h | 11 +++
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/parity_64.S | 142 +++++++++++++++++++++++++++
arch/powerpc/lib/ppc_ksyms.c | 5 +
arch/s390/include/asm/bitops.h | 1 +
arch/sh/include/asm/bitops.h | 1 +
arch/sparc/include/asm/bitops_32.h | 1 +
arch/sparc/include/asm/bitops_64.h | 18 ++++
arch/sparc/kernel/sparc_ksyms_64.c | 6 ++
arch/sparc/lib/Makefile | 2 +-
arch/sparc/lib/parity.S | 128 ++++++++++++++++++++++++
arch/tile/include/asm/bitops.h | 2 +
arch/x86/include/asm/arch_hweight.h | 5 +
arch/x86/include/asm/arch_parity.h | 117 ++++++++++++++++++++++
arch/x86/include/asm/bitops.h | 4 +-
arch/xtensa/include/asm/bitops.h | 1 +
drivers/crypto/qat/qat_common/qat_hal.c | 32 ++----
drivers/iio/gyro/adxrs450.c | 4 +-
drivers/input/joystick/grip_mp.c | 16 +--
drivers/input/joystick/sidewinder.c | 24 +----
drivers/input/mouse/elantech.c | 10 +-
drivers/input/mouse/elantech.h | 1 -
drivers/input/serio/ams_delta_serio.c | 8 +-
drivers/input/serio/pcips2.c | 2 +-
drivers/input/serio/sa1111ps2.c | 2 +-
drivers/media/i2c/saa7115.c | 17 +---
drivers/media/platform/vivid/vivid-vbi-gen.c | 9 +-
drivers/mtd/inftlcore.c | 17 +---
drivers/mtd/sm_ftl.c | 5 +-
drivers/mtd/ssfdc.c | 31 ++----
drivers/net/ethernet/broadcom/tg3.c | 6 +-
drivers/net/ethernet/sun/niu.c | 10 +-
drivers/scsi/isci/phy.c | 15 +--
drivers/tty/serial/max3100.c | 2 +-
include/asm-generic/bitops.h | 1 +
include/asm-generic/bitops/arch_parity.h | 39 ++++++++
include/asm-generic/bitops/const_parity.h | 36 +++++++
include/asm-generic/bitops/parity.h | 7 ++
include/asm-generic/bitops/popc-parity.h | 32 ++++++
include/linux/bitops.h | 10 ++
lib/bch.c | 14 +--
net/sunrpc/auth_gss/gss_krb5_keys.c | 6 +-
62 files changed, 745 insertions(+), 235 deletions(-)
create mode 100644 arch/powerpc/lib/parity_64.S
create mode 100644 arch/sparc/lib/parity.S
create mode 100644 arch/x86/include/asm/arch_parity.h
create mode 100644 include/asm-generic/bitops/arch_parity.h
create mode 100644 include/asm-generic/bitops/const_parity.h
create mode 100644 include/asm-generic/bitops/parity.h
create mode 100644 include/asm-generic/bitops/popc-parity.h
--
2.5.0
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Use passed in table for nexthop lookups
From: David Ahern @ 2016-04-14 4:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160413.214151.2294488534397440295.davem@davemloft.net>
On 4/13/16 7:41 PM, David Miller wrote:
> This is semantically different from the referenced ipv4 change.
>
> Lack of a matching table for cfg->fc_table does not result in a
> failure on the ipv4 side. It falls back in that case.
>
> But here in this ipv6 patch, you do fail if fib6_get_table() gives
> NULL.
Unintentional. I meant for this to behave exactly like the ipv4 change.
>
> One thing that drives me absolutely crazy is all of the subtle
> semantic differences between our ipv4 and ipv6 stack, so I refuse to
> knowingly add new such cases.
I feel that pain on a daily basis.
>
> Therefore, please make the ipv6 behavior match exactly what ipv4
> does.
Will remove the goto out on the table lookup fail and have it fallback
to current logic. Thanks for catching that difference.
^ permalink raw reply
* RE: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets
From: Dexuan Cui @ 2016-04-14 3:56 UTC (permalink / raw)
To: David Miller
Cc: olaf@aepfle.de, gregkh@linuxfoundation.org, jasowang@redhat.com,
linux-kernel@vger.kernel.org, joe@perches.com,
netdev@vger.kernel.org, apw@canonical.com,
devel@linuxdriverproject.org, Haiyang Zhang
In-Reply-To: <20160413.223027.844777521863481943.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, April 14, 2016 10:30
> To: Dexuan Cui <decui@microsoft.com>
> Cc: gregkh@linuxfoundation.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com; cavery@redhat.com; KY
> Srinivasan <kys@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>;
> joe@perches.com; vkuznets@redhat.com
> Subject: Re: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets
>
> From: Dexuan Cui <decui@microsoft.com>
> Date: Thu, 7 Apr 2016 18:36:51 -0700
>
> > +struct vmpipe_proto_header {
> > + u32 pkt_type;
> > + u32 data_size;
> > +} __packed;
>
> There is no reason to specify __packed here.
>
> The types are strongly sized to word aligned quantities.
> No holes are possible in this structure, nor is any padding
> possible either.
>
> Do not ever slap __packed onto protocol or HW defined structures,
> simply just define them properly with proper types and explicit
> padding when necessary.
Hi David,
Thank you very much for taking a look at the patch!
I'll remove all the 3 __packed usages in my patch.
> > + struct {
> > + struct vmpipe_proto_header hdr;
> > + char buf[HVSOCK_SND_BUF_SZ];
> > + } __packed send;
>
> And so on, and so forth..
I'll remove __packed and use u8 to replace the 'char' here.
> I'm really disappointed that I couldn't even get one hunk into this
> patch submission without finding a major problem.
David,
Could you please point out more issues in the patch?
I'm definitely happy to fix them. :-)
> I expect this patch to take several more iterations before I can even
> come close to applying it. So please set your expectations properly,
> and also it seems like nobody else wants to even review this stuff
> either. It is you who needs to find a way to change all of this, not
> me.
A few people took a look at the early versions of the patch and did
give me good suggestions on the interface APIs with VMBus and
some coding style issues, especially Vitaly from Redhat.
Cathy from Redhat was also looking into the patch recently and
gave me some good feedbacks.
I'll try to invite more people to review the patch.
And, I'm updating the patch to address some issues:
1) the feature is only properly supported on Windows 10/2016
build 14290 and later, so I'm going to not enable the feature on
old hosts.
2) there is actually some mechanism we can use to simplify
hvsock_open_connection() and help to better support
hvsock_shutdown().
Thanks,
-- Dexuan
^ permalink raw reply
* [net 2/2] fm10k: fix multi-bit VLAN update requests from VF
From: Jeff Kirsher @ 2016-04-14 3:47 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1460605632-112945-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The VF uses a multi-bit update request to clear unused VLANs whenever it
resets. However, an accident in a previous refector broke multi-bit
updates for VFs, due to misreading a comment in fm10k_vf.c and
attempting to reduce code duplication. The problem occurs because
a multi-bit request has a non-zero length, and the PF would simply drop
any request with the upper 16 bits set.
We can't simply remove the check of the upper 16 bits and the call to
fm10k_iov_select vid, because this would remove the checks for default
VID and for ensuring no other VLANs can be enabled except pf_vid when it
has been set. To resolve that issue, this revision uses the
iov_select_vid when we have a single-bit update, and denies any
multi-bit update when the VLAN was administratively set by the PF. This
should be ok since the PF properly updates VLAN_TABLE when it assigns
the PF vid. This ensures that requests to add or remove the PF vid work
as expected, but a rogue VF could not use the multi-bit update as
a loophole to attempt receiving traffic on other VLANs.
Reported-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 30 +++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
index 62ccebc..8cf943d 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
@@ -1223,18 +1223,32 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 **results,
if (err)
return err;
- /* verify upper 16 bits are zero */
- if (vid >> 16)
- return FM10K_ERR_PARAM;
-
set = !(vid & FM10K_VLAN_CLEAR);
vid &= ~FM10K_VLAN_CLEAR;
- err = fm10k_iov_select_vid(vf_info, (u16)vid);
- if (err < 0)
- return err;
+ /* if the length field has been set, this is a multi-bit
+ * update request. For multi-bit requests, simply disallow
+ * them when the pf_vid has been set. In this case, the PF
+ * should have already cleared the VLAN_TABLE, and if we
+ * allowed them, it could allow a rogue VF to receive traffic
+ * on a VLAN it was not assigned. In the single-bit case, we
+ * need to modify requests for VLAN 0 to use the default PF or
+ * SW vid when assigned.
+ */
- vid = err;
+ if (vid >> 16) {
+ /* prevent multi-bit requests when PF has
+ * administratively set the VLAN for this VF
+ */
+ if (vf_info->pf_vid)
+ return FM10K_ERR_PARAM;
+ } else {
+ err = fm10k_iov_select_vid(vf_info, (u16)vid);
+ if (err < 0)
+ return err;
+
+ vid = err;
+ }
/* update VSI info for VF in regards to VLAN table */
err = hw->mac.ops.update_vlan(hw, vid, vf_info->vsi, set);
--
2.5.5
^ permalink raw reply related
* [net 1/2] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Jeff Kirsher @ 2016-04-14 3:47 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1460605632-112945-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <aduyck@mirantis.com>
This patch addresses a bug introduced based on my interpretation of the
XL710 datasheet. Specifically section 8.4.1 states that "A single transmit
packet may span up to 8 buffers (up to 8 data descriptors per packet
including both the header and payload buffers)." It then later goes on to
say that each segment for a TSO obeys the previous rule, however it then
refers to TSO header and the segment payload buffers.
I believe the actual limit for fragments with TSO and a skbuff that has
payload data in the header portion of the buffer is actually only 7
fragments as the skb->data portion counts as 2 buffers, one for the TSO
header, and one for a segment payload buffer.
Fixes: 2d37490b82af ("i40e/i40evf: Rewrite logic for 8 descriptor per packet check")
Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 10 ++++--
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40evf/i40e_txrx.h | 10 ++++--
4 files changed, 62 insertions(+), 56 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 084d0ab..6a49b7a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2594,35 +2594,34 @@ int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
}
/**
- * __i40e_chk_linearize - Check if there are more than 8 fragments per packet
+ * __i40e_chk_linearize - Check if there are more than 8 buffers per packet
* @skb: send buffer
*
- * Note: Our HW can't scatter-gather more than 8 fragments to build
- * a packet on the wire and so we need to figure out the cases where we
- * need to linearize the skb.
+ * Note: Our HW can't DMA more than 8 buffers to build a packet on the wire
+ * and so we need to figure out the cases where we need to linearize the skb.
+ *
+ * For TSO we need to count the TSO header and segment payload separately.
+ * As such we need to check cases where we have 7 fragments or more as we
+ * can potentially require 9 DMA transactions, 1 for the TSO header, 1 for
+ * the segment payload in the first descriptor, and another 7 for the
+ * fragments.
**/
bool __i40e_chk_linearize(struct sk_buff *skb)
{
const struct skb_frag_struct *frag, *stale;
- int gso_size, nr_frags, sum;
-
- /* check to see if TSO is enabled, if so we may get a repreive */
- gso_size = skb_shinfo(skb)->gso_size;
- if (unlikely(!gso_size))
- return true;
+ int nr_frags, sum;
- /* no need to check if number of frags is less than 8 */
+ /* no need to check if number of frags is less than 7 */
nr_frags = skb_shinfo(skb)->nr_frags;
- if (nr_frags < I40E_MAX_BUFFER_TXD)
+ if (nr_frags < (I40E_MAX_BUFFER_TXD - 1))
return false;
/* We need to walk through the list and validate that each group
* of 6 fragments totals at least gso_size. However we don't need
- * to perform such validation on the first or last 6 since the first
- * 6 cannot inherit any data from a descriptor before them, and the
- * last 6 cannot inherit any data from a descriptor after them.
+ * to perform such validation on the last 6 since the last 6 cannot
+ * inherit any data from a descriptor after them.
*/
- nr_frags -= I40E_MAX_BUFFER_TXD - 1;
+ nr_frags -= I40E_MAX_BUFFER_TXD - 2;
frag = &skb_shinfo(skb)->frags[0];
/* Initialize size to the negative value of gso_size minus 1. We
@@ -2631,21 +2630,21 @@ bool __i40e_chk_linearize(struct sk_buff *skb)
* descriptors for a single transmit as the header and previous
* fragment are already consuming 2 descriptors.
*/
- sum = 1 - gso_size;
+ sum = 1 - skb_shinfo(skb)->gso_size;
- /* Add size of frags 1 through 5 to create our initial sum */
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
+ /* Add size of frags 0 through 4 to create our initial sum */
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
stale = &skb_shinfo(skb)->frags[0];
for (;;) {
- sum += skb_frag_size(++frag);
+ sum += skb_frag_size(frag++);
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
@@ -2655,7 +2654,7 @@ bool __i40e_chk_linearize(struct sk_buff *skb)
if (!--nr_frags)
break;
- sum -= skb_frag_size(++stale);
+ sum -= skb_frag_size(stale++);
}
return false;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.h b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
index cdd5dc0..a9bd705 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
@@ -413,10 +413,14 @@ static inline int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
**/
static inline bool i40e_chk_linearize(struct sk_buff *skb, int count)
{
- /* we can only support up to 8 data buffers for a single send */
- if (likely(count <= I40E_MAX_BUFFER_TXD))
+ /* Both TSO and single send will work if count is less than 8 */
+ if (likely(count < I40E_MAX_BUFFER_TXD))
return false;
- return __i40e_chk_linearize(skb);
+ if (skb_is_gso(skb))
+ return __i40e_chk_linearize(skb);
+
+ /* we can support up to 8 data buffers for a single send */
+ return count != I40E_MAX_BUFFER_TXD;
}
#endif /* _I40E_TXRX_H_ */
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index ebcc25c..cea97da 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1796,35 +1796,34 @@ static void i40e_create_tx_ctx(struct i40e_ring *tx_ring,
}
/**
- * __i40evf_chk_linearize - Check if there are more than 8 fragments per packet
+ * __i40evf_chk_linearize - Check if there are more than 8 buffers per packet
* @skb: send buffer
*
- * Note: Our HW can't scatter-gather more than 8 fragments to build
- * a packet on the wire and so we need to figure out the cases where we
- * need to linearize the skb.
+ * Note: Our HW can't DMA more than 8 buffers to build a packet on the wire
+ * and so we need to figure out the cases where we need to linearize the skb.
+ *
+ * For TSO we need to count the TSO header and segment payload separately.
+ * As such we need to check cases where we have 7 fragments or more as we
+ * can potentially require 9 DMA transactions, 1 for the TSO header, 1 for
+ * the segment payload in the first descriptor, and another 7 for the
+ * fragments.
**/
bool __i40evf_chk_linearize(struct sk_buff *skb)
{
const struct skb_frag_struct *frag, *stale;
- int gso_size, nr_frags, sum;
-
- /* check to see if TSO is enabled, if so we may get a repreive */
- gso_size = skb_shinfo(skb)->gso_size;
- if (unlikely(!gso_size))
- return true;
+ int nr_frags, sum;
- /* no need to check if number of frags is less than 8 */
+ /* no need to check if number of frags is less than 7 */
nr_frags = skb_shinfo(skb)->nr_frags;
- if (nr_frags < I40E_MAX_BUFFER_TXD)
+ if (nr_frags < (I40E_MAX_BUFFER_TXD - 1))
return false;
/* We need to walk through the list and validate that each group
* of 6 fragments totals at least gso_size. However we don't need
- * to perform such validation on the first or last 6 since the first
- * 6 cannot inherit any data from a descriptor before them, and the
- * last 6 cannot inherit any data from a descriptor after them.
+ * to perform such validation on the last 6 since the last 6 cannot
+ * inherit any data from a descriptor after them.
*/
- nr_frags -= I40E_MAX_BUFFER_TXD - 1;
+ nr_frags -= I40E_MAX_BUFFER_TXD - 2;
frag = &skb_shinfo(skb)->frags[0];
/* Initialize size to the negative value of gso_size minus 1. We
@@ -1833,21 +1832,21 @@ bool __i40evf_chk_linearize(struct sk_buff *skb)
* descriptors for a single transmit as the header and previous
* fragment are already consuming 2 descriptors.
*/
- sum = 1 - gso_size;
+ sum = 1 - skb_shinfo(skb)->gso_size;
- /* Add size of frags 1 through 5 to create our initial sum */
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
+ /* Add size of frags 0 through 4 to create our initial sum */
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
stale = &skb_shinfo(skb)->frags[0];
for (;;) {
- sum += skb_frag_size(++frag);
+ sum += skb_frag_size(frag++);
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
@@ -1857,7 +1856,7 @@ bool __i40evf_chk_linearize(struct sk_buff *skb)
if (!--nr_frags)
break;
- sum -= skb_frag_size(++stale);
+ sum -= skb_frag_size(stale++);
}
return false;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.h b/drivers/net/ethernet/intel/i40evf/i40e_txrx.h
index c1dd8c5..0429553 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.h
@@ -395,10 +395,14 @@ static inline int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
**/
static inline bool i40e_chk_linearize(struct sk_buff *skb, int count)
{
- /* we can only support up to 8 data buffers for a single send */
- if (likely(count <= I40E_MAX_BUFFER_TXD))
+ /* Both TSO and single send will work if count is less than 8 */
+ if (likely(count < I40E_MAX_BUFFER_TXD))
return false;
- return __i40evf_chk_linearize(skb);
+ if (skb_is_gso(skb))
+ return __i40evf_chk_linearize(skb);
+
+ /* we can support up to 8 data buffers for a single send */
+ return count != I40E_MAX_BUFFER_TXD;
}
#endif /* _I40E_TXRX_H_ */
--
2.5.5
^ permalink raw reply related
* [net 0/2][pull request] Intel Wired LAN Driver Updates 2016-04-13
From: Jeff Kirsher @ 2016-04-14 3:47 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene, john.ronciak
This series contains updates to i40e, i40evf and fm10k.
Alex fixes a bug introduced earlier based on his interpretation of the
XL710 datasheet. The actual limit for fragments with TSO and a skbuff
that has payload data in the header portion of the buffer is actually
only 7 fragments and the skb-data portion counts as 2 buffers, one for
the TSO header, and the one for a segment payload buffer.
Jacob fixes a bug where in a previous refactor of the code broke
multi-bit updates for VFs. The problem occurs because a multi-bit
request has a non-zero length, and the PF would simply drop any
request with the upper 16 bits set.
The following are changes since commit a6d37131c02f15463daa00e2f1da6824e8e00de2:
net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue master
Alexander Duyck (1):
i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per
packet
Jacob Keller (1):
fm10k: fix multi-bit VLAN update requests from VF
drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 30 +++++++++++-----
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 10 ++++--
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40evf/i40e_txrx.h | 10 ++++--
5 files changed, 84 insertions(+), 64 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: [RESEND PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode
From: Weidong Wang @ 2016-04-14 3:42 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, netdev, linux-kernel, andrew
In-Reply-To: <570E92ED.9020603@gmail.com>
On 2016/4/14 2:41, Florian Fainelli wrote:
> On 13/04/16 04:59, Weidong Wang wrote:
>> When tested the PHY SGMII Loopback,:
>> 1.set the LOOPBACK bit,
>> 2.set the autoneg to AUTONEG_DISABLE, it calls the
>> genphy_setup_forced which will clear the bit.
>>
>> So just keep the LOOPBACK bit while setup forced mode.
>
> Humm, it makes sense why we want this one, but maybe we want other bits
> to be preserved too, like MII_ISOLATE for instance?
>
I will add the MII_ISOLATE as well.
> Or maybe we should have a separate way to put the PHY into loopback mode
> which is deterministic and takes care of forcing the link at the same time?
>
I test with the loopback mode, and the link status is undeterminable.
>>
>> Signed-off-by: Weidong Wang <wangweidong1@huawei.com>
>> ---
>> drivers/net/phy/phy_device.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index e551f3a..8da4b80 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1124,7 +1124,9 @@ static int genphy_config_advert(struct phy_device *phydev)
>> int genphy_setup_forced(struct phy_device *phydev)
>> {
>> int ctl = 0;
>> + int val = phy_read(phydev, MII_BMCR);
>>
>> + ctl |= val & BMCR_LOOPBACK;
>> phydev->pause = 0;
>> phydev->asym_pause = 0;
>>
>> -- 2.7.0
>>
>
>
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: use __napi_schedule_irqoff()
From: David Miller @ 2016-04-14 3:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: f.fainelli, netdev, pgynther, opendmb
In-Reply-To: <1460179856.6473.482.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 08 Apr 2016 22:30:56 -0700
> From: Florian Fainelli <f.fainelli@gmail.com>
>
> bcmgenet_isr1() and bcmgenet_isr0() run in hard irq context,
> we do not need to block irq again.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: use napi_complete_done()
From: David Miller @ 2016-04-14 3:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, pgynther, f.fainelli
In-Reply-To: <1460178400.6473.469.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 08 Apr 2016 22:06:40 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> By using napi_complete_done(), we allow fine tuning
> of /sys/class/net/ethX/gro_flush_timeout for higher GRO aggregation
> efficiency for a Gbit NIC.
>
> Check commit 24d2e4a50737 ("tg3: use napi_complete_done()") for details.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [net-next][PATCH 0/2] RDS: couple of fixes for 4.6
From: David Miller @ 2016-04-14 3:36 UTC (permalink / raw)
To: santosh.shilimkar; +Cc: netdev, linux-kernel
In-Reply-To: <1460154400-14546-1-git-send-email-santosh.shilimkar@oracle.com>
From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Date: Fri, 8 Apr 2016 15:26:38 -0700
> Patches are also available at below git tree.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_4.6/net-next/rds-fixes
"Bug fixes for 4.6" do not get targetted at the net-next tree, that's
for 4.7 development.
^ permalink raw reply
* Re: [PATCH v4] route: do not cache fib route info on local routes with oif
From: David Miller @ 2016-04-14 3:34 UTC (permalink / raw)
To: chris.friesen; +Cc: ja, netdev
In-Reply-To: <570820DA.2070007@windriver.com>
From: Chris Friesen <chris.friesen@windriver.com>
Date: Fri, 8 Apr 2016 15:21:30 -0600
> For local routes that require a particular output interface we do not want
> to cache the result. Caching the result causes incorrect behaviour when
> there are multiple source addresses on the interface. The end result
> being that if the intended recipient is waiting on that interface for the
> packet he won't receive it because it will be delivered on the loopback
> interface and the IP_PKTINFO ipi_ifindex will be set to the loopback
> interface as well.
>
> This can be tested by running a program such as "dhcp_release" which
> attempts to inject a packet on a particular interface so that it is
> received by another program on the same board. The receiving process
> should see an IP_PKTINFO ipi_ifndex value of the source interface
> (e.g., eth1) instead of the loopback interface (e.g., lo). The packet
> will still appear on the loopback interface in tcpdump but the important
> aspect is that the CMSG info is correct.
>
> Sample dhcp_release command line:
>
> dhcp_release eth1 192.168.204.222 02:11:33:22:44:66
>
> Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
> Signed off-by: Chris Friesen <chris.friesen@windriver.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] [v4] net: emac: emac gigabit ethernet controller driver
From: kbuild test robot @ 2016-04-14 3:27 UTC (permalink / raw)
To: Timur Tabi
Cc: kbuild-all-JC7UmRfGjtg, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
sdharia-sgV2jX0FEOL9JmXXK+q4OQ, Shanker Donthineni,
Greg Kroah-Hartman, vikrams-sgV2jX0FEOL9JmXXK+q4OQ,
cov-sgV2jX0FEOL9JmXXK+q4OQ, gavidov-sgV2jX0FEOL9JmXXK+q4OQ,
Rob Herring, andrew-g2DYL2Zd6BY,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Mark Langsdorf,
Jon Masters, Andy Gross, David S. Miller
In-Reply-To: <1460570393-19838-1-git-send-email-timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]
Hi Gilad,
[auto build test WARNING on net/master]
[also build test WARNING on v4.6-rc3 next-20160413]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Timur-Tabi/net-emac-emac-gigabit-ethernet-controller-driver/20160414-020345
config: ia64-allyesconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
In file included from arch/ia64/include/asm/smp.h:20:0,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from include/linux/textsearch.h:8,
from include/linux/skbuff.h:30,
from include/linux/tcp.h:21,
from drivers/net/ethernet/qualcomm/emac/emac-mac.c:16:
drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
arch/ia64/include/asm/io.h:395:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define writel(v,a) __writel((v), (a))
^
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c:1076:2: note: in expansion of macro 'writel'
writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
^
vim +/writel +1076 drivers/net/ethernet/qualcomm/emac/emac-mac.c
1060 return ret;
1061
1062 ret = request_irq(irq->irq, emac_isr, 0, EMAC_MAC_IRQ_RES, irq);
1063 if (ret) {
1064 netdev_err(adpt->netdev,
1065 "error:%d on request_irq(%d:%s flags:0)\n", ret,
1066 irq->irq, EMAC_MAC_IRQ_RES);
1067 emac_sgmii_down(adpt);
1068 return ret;
1069 }
1070
1071 emac_mac_rx_descs_refill(adpt, &adpt->rx_q);
1072
1073 napi_enable(&adpt->rx_q.napi);
1074
1075 /* enable mac irq */
> 1076 writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
1077 writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
1078
1079 netif_start_queue(netdev);
1080 clear_bit(EMAC_STATUS_DOWN, &adpt->status);
1081
1082 /* check link status */
1083 set_bit(EMAC_STATUS_TASK_LSC_REQ, &adpt->status);
1084 adpt->link_chk_timeout = jiffies + EMAC_TRY_LINK_TIMEOUT;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 45884 bytes --]
^ permalink raw reply
* Re: [PATCH] net: ipv6: Do not keep linklocal and loopback addresses
From: David Ahern @ 2016-04-14 3:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160413.230002.1718430497071707670.davem@davemloft.net>
On 4/13/16 9:00 PM, David Miller wrote:
>
> Applied, but two things:
>
> Please do not put an empty line between the Fixes: and other tags.
> All tags are equal and should be placed together as an unsegmented
> unit.
ack.
> Second, please be really sure this is the final set of semantics
> you want. If we flap again on this after 4.6-final goes out the
> door, I will be very unpleased to say the least.
(thunderbird underlined unpleased in that sentence as if you reached
through the screen and and put a red marker on it)
With this patch we only retain user configured addresses which is the
goal of the v1 patch posted back in January 2015. This is active in our
code base so getting a lot of testing and exposure to other users. It is
active on my server and VMs as well. With all of the VRF testing it is
getting a workout. i.e, not much more I can do to ensure this is solid
before 4.6 is final. I know this patch has been been ported and is in
use by others; I would encourage them to share if they see problems or
want adjustments as well.
^ permalink raw reply
* [PATCH V3 29/29] ethernet: use parity8 in broadcom/tg3.c
From: zengzhaoxiu @ 2016-04-14 3:12 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, Siva Reddy Kallam, Prashant Sreedharan,
Michael Chan, netdev
In-Reply-To: <1460601525-3822-1-git-send-email-zengzhaoxiu@163.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/broadcom/tg3.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 3010080..802a429 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
err = -EIO;
for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
- u8 hw8 = hweight8(data[i]);
-
- if ((hw8 & 0x1) && parity[i])
- goto out;
- else if (!(hw8 & 0x1) && !parity[i])
+ if (parity8(data[i]) == !!parity[i])
goto out;
}
err = 0;
--
2.5.0
^ permalink raw reply related
* [PATCH V3 23/29] ethernet: use parity8 in sun/niu.c
From: zengzhaoxiu @ 2016-04-14 3:11 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, Joonsoo Kim, Vlastimil Babka, David S. Miller,
Andrew Morton, Jiri Pirko, netdev
In-Reply-To: <1460601525-3822-1-git-send-email-zengzhaoxiu@163.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/sun/niu.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 9cc4564..8c344ef 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -2742,18 +2742,12 @@ static int niu_set_alt_mac_rdc_table(struct niu *np, int idx,
static u64 vlan_entry_set_parity(u64 reg_val)
{
- u64 port01_mask;
- u64 port23_mask;
-
- port01_mask = 0x00ff;
- port23_mask = 0xff00;
-
- if (hweight64(reg_val & port01_mask) & 1)
+ if (parity8(reg_val))
reg_val |= ENET_VLAN_TBL_PARITY0;
else
reg_val &= ~ENET_VLAN_TBL_PARITY0;
- if (hweight64(reg_val & port23_mask) & 1)
+ if (parity8((unsigned int)reg_val >> 8))
reg_val |= ENET_VLAN_TBL_PARITY1;
else
reg_val &= ~ENET_VLAN_TBL_PARITY1;
--
2.5.0
^ permalink raw reply related
* [PATCH V3 10/29] sunrpc: use parity8
From: zengzhaoxiu @ 2016-04-14 3:08 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, J. Bruce Fields, Jeff Layton, Trond Myklebust,
Anna Schumaker, David S. Miller, Herbert Xu, linux-nfs, netdev
In-Reply-To: <1460601525-3822-1-git-send-email-zengzhaoxiu@163.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
net/sunrpc/auth_gss/gss_krb5_keys.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 8701331..c41b389 100644
--- a/net/sunrpc/auth_gss/gss_krb5_keys.c
+++ b/net/sunrpc/auth_gss/gss_krb5_keys.c
@@ -243,16 +243,12 @@ err_return:
return ret;
}
-#define smask(step) ((1<<step)-1)
-#define pstep(x, step) (((x)&smask(step))^(((x)>>step)&smask(step)))
-#define parity_char(x) pstep(pstep(pstep((x), 4), 2), 1)
-
static void mit_des_fixup_key_parity(u8 key[8])
{
int i;
for (i = 0; i < 8; i++) {
key[i] &= 0xfe;
- key[i] |= 1^parity_char(key[i]);
+ key[i] |= !parity8(key[i]);
}
}
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v3 0/2] sctp: delay calls to sk_data_ready() as much as possible
From: David Miller @ 2016-04-14 3:05 UTC (permalink / raw)
To: marcelo.leitner
Cc: netdev, vyasevich, nhorman, linux-sctp, David.Laight, jkbs
In-Reply-To: <cover.1460144373.git.marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Fri, 8 Apr 2016 16:41:26 -0300
> 1st patch is a preparation for the 2nd. The idea is to not call
> ->sk_data_ready() for every data chunk processed while processing
> packets but only once before releasing the socket.
>
> v2: patchset re-checked, small changelog fixes
> v3: on patch 2, make use of local vars to make it more readable
Applied to net-next, but isn't this reduced overhead coming at the
expense of latency? What if that lower latency is important to the
application and/or consumer?
^ permalink raw reply
* Re: [PATCH] mISDN: Fixing missing validation in base_sock_bind()
From: David Miller @ 2016-04-14 3:01 UTC (permalink / raw)
To: ed; +Cc: linux-kernel, netdev, isdn
In-Reply-To: <1460142971-16459-1-git-send-email-ed@abdsec.com>
From: Emrah Demir <ed@abdsec.com>
Date: Fri, 8 Apr 2016 22:16:11 +0300
> From: Emrah Demir <ed@abdsec.com>
>
> Add validation code into mISDN/socket.c
>
> Signed-off-by: Emrah Demir <ed@abdsec.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ipv6: Do not keep linklocal and loopback addresses
From: David Miller @ 2016-04-14 3:00 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1460142081-16675-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Fri, 8 Apr 2016 12:01:21 -0700
> f1705ec197e7 added the option to retain user configured addresses on an
> admin down. A comment to one of the later revisions suggested using the
> IFA_F_PERMANENT flag rather than adding a user_managed boolean to the
> ifaddr struct. A side effect of this change is that link local and
> loopback addresses are also retained which is not part of the objective
> of f1705ec197e7. Add check to drop those addresses.
>
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied, but two things:
Please do not put an empty line between the Fixes: and other tags.
All tags are equal and should be placed together as an unsegmented
unit.
Second, please be really sure this is the final set of semantics
you want. If we flap again on this after 4.6-final goes out the
door, I will be very unpleased to say the least.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] fix two more udp pull header issues
From: Willem de Bruijn @ 2016-04-14 2:57 UTC (permalink / raw)
To: David Miller
Cc: Network Development, Tom Herbert, Sam Kumar, Willem de Bruijn
In-Reply-To: <20160413.222554.1942915187151383805.davem@davemloft.net>
On Wed, Apr 13, 2016 at 10:25 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Thu, 7 Apr 2016 18:12:57 -0400
>
>> Follow up patches to the fixes to RxRPC and SunRPC. A scan of the
>> code showed two other interfaces that expect UDP packets to have
>> a udphdr when queued: read packet length with ioctl SIOCINQ and
>> receive payload checksum with socket option IP_CHECKSUM.
>
> As we are seeing, lots of places depend upon the old way of queueing
> up UDP frames. :-/
Yes, I greatly underestimated that. I should have done a much more
thorough scan before submitting. Hopefully we've caught them all now.
> Applied, thanks for mopping all of this up.
Apologies for breaking it in the first place!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox