* Re: [PATCH net-next] ipv4: fix a race in update_or_create_fnhe()
From: David Miller @ 2014-09-06 0:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1409808116.26422.83.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 03 Sep 2014 22:21:56 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> nh_exceptions is effectively used under rcu, but lacks proper
> barriers. Between kzalloc() and setting of nh->nh_exceptions(),
> we need a proper memory barrier.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: 4895c771c7f00 ("ipv4: Add FIB nexthop exceptions.")
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: ethernet: cpsw: improve interrupt lookup logic in cpsw_probe()
From: David Miller @ 2014-09-06 0:17 UTC (permalink / raw)
To: daniel; +Cc: julia.lawall, netdev, mugunthanvnm, george.cherian, zonque
In-Reply-To: <1409814023-10189-1-git-send-email-daniel@zonque.org>
From: Daniel Mack <daniel@zonque.org>
Date: Thu, 4 Sep 2014 09:00:23 +0200
> From: Daniel Mack <zonque@gmail.com>
>
> Simplify the interrupt resource lookup code in cpsw_probe() by the
> following:
>
> * Only look at the first member of the resource. As the driver only
> works for DT-enabled platforms anyway, a resource of type
> IORESOURCE_IRQ will only contain one single entry
> (res->start == res->end), so there is no need for the iteration.
>
> * Add a bounds check to avoid overflows if we are passed more than
> ARRAY_SIZE(priv->irqs_table) resources.
>
> * Assign 'ret' with the return value of devm_request_irq() so that
> cpsw_probe() returns the appropriate error code.
>
> * If devm_request_irq() fails, report the error code in the log
> message.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [net-next v4 0/3] Refactor vxlan and l2tp to use common UDP tunnel APIs
From: David Miller @ 2014-09-06 0:19 UTC (permalink / raw)
To: azhou; +Cc: netdev
In-Reply-To: <1409817462-7957-1-git-send-email-azhou@nicira.com>
From: Andy Zhou <azhou@nicira.com>
Date: Thu, 4 Sep 2014 00:57:39 -0700
> Andy Zhou (3):
> udp-tunnel: Expand UDP tunnel APIs
> vxlan: Refactor vxlan driver to make use of the common UDP tunnel
> functions.
> l2tp: Refactor l2tp core driver to make use of the common UDP tunnel
> functions
Way too many ifdefs in *.c code, and your indentation is not correct.
For function calls that span multiple lines, you must start the second
and subsequent lines exactly at the first column after the openning
parenthesis of the first line. You must use the appropriate number of
TAB and SPACE characters necessary to do so. If you are indenting these
lines only using TAB characters, you are very likely doing it wrong.
Thanks.
^ permalink raw reply
* Re: [PATCH iproute2] ip: support of usec rtt in tcp_metrics
From: Eric Dumazet @ 2014-09-06 0:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20140905170222.1599ad33@urahara>
On Fri, 2014-09-05 at 17:02 -0700, Stephen Hemminger wrote:
> On Fri, 05 Sep 2014 16:54:04 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > + if (i != TCP_METRIC_RTT &&
> > + i != TCP_METRIC_RTT_US &&
> > + i != TCP_METRIC_RTTVAR &&
> > + i != TCP_METRIC_RTTVAR_US) {
> > + if (metric_name[i])
> > + fprintf(fp, " %s ", metric_name[i]);
> > + else
> > + fprintf(fp, " metric_%d ", i);
>
> Why not put new metrics in metric_name array? and make the check something like:
>
> if (i < ARRAY_SIZE(metric_name) && metric_name[i])
> fprintf(fp, " %s ", metric_name[i]);
> else
> fprintf(fp, " metric_%d ", i)
>
> This makes it future proof, and gets rid of the silly test.
Because for compatibility reasons, kernel gives all values,
we want to output one of them, the most accurate one.
^ permalink raw reply
* Re: [net-next v2 00/15][pull request] Intel Wired LAN Driver Updates 2014-09-04
From: David Miller @ 2014-09-06 0:23 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1409820404-18053-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 4 Sep 2014 01:46:29 -0700
> This series contains updates to i40e, i40evf, ixgbe and ixgbevf.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] netfilter: add explicit Kconfig for NETFILTER_XT_NAT
From: David Miller @ 2014-09-06 0:23 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev, pebolle
In-Reply-To: <1409816841-6446-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 4 Sep 2014 09:47:21 +0200
> Paul Bolle reports that 'select NETFILTER_XT_NAT' from the IPV4 and IPV6
> NAT tables becomes noop since there is no Kconfig switch for it. Add the
> Kconfig switch to resolve this problem.
>
> Fixes: 8993cf8 netfilter: move NAT Kconfig switches out of the iptables scope
> Reported-by: Paul Bolle <pebolle@tiscali.nl>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Applied, thanks Pablo.
^ permalink raw reply
* Re: [PATCH v3] 3c59x: avoid panic in boomerang_start_xmit when finding page address:
From: David Miller @ 2014-09-06 0:24 UTC (permalink / raw)
To: nhorman; +Cc: netdev, klassert
In-Reply-To: <1409825618-30785-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 4 Sep 2014 06:13:38 -0400
> This bug was reported on a very old kernel (RHEL6, 2.6.32-491.el6):
...
> But the problem seems to still exist upstream. It seems on 32 bit kernels
> page_address() can reutrn a NULL value in some circumstances, and the
> pci_map_single api isn't prepared to handle that (on this system it results in a
> bogus pointer deference in nommu_map_page.
>
> The fix is pretty easy, if we convert the 3c59x driver to use the more
> convieient skb_frag_dma_map api we don't need to find the virtual address of the
> page at all, and page gets mapped to the hardware properly. Verified to fix the
> problem as described by the reporter.
>
> Applies to the net tree
>
> Change Notes:
>
> v2) Converted PCI_DMA_TODEVICE to DMA_TO_DEVICE. Thanks Dave!
>
> v3) Actually Run git commit after making changes to v2 :)
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks Neil.
^ permalink raw reply
* Re: [PATCH net] bnx2x: Fix link problems for 1G SFP RJ45 module
From: David Miller @ 2014-09-06 0:28 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, Ariel.Elior, Yaniv.Rosner
In-Reply-To: <1409826360-32534-1-git-send-email-Yuval.Mintz@qlogic.com>
From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Thu, 4 Sep 2014 13:26:00 +0300
> From: Yaniv Rosner <Yaniv.Rosner@qlogic.com>
>
> When 1G SFP RJ45 module is detected, driver must reset the Tx laser
> in order to prevent link issues. As part of change, the link_attr_sync
> was relocated from vars to params.
>
> Signed-off-by: Yaniv Rosner <Yaniv.Rosner@qlogic.com>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Applied.
^ permalink raw reply
* Re: [patch -next] hyperv: NULL dereference on error
From: David Miller @ 2014-09-06 0:29 UTC (permalink / raw)
To: dan.carpenter; +Cc: kys, haiyangz, devel, netdev, kernel-janitors
In-Reply-To: <20140904111123.GD21504@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 4 Sep 2014 14:11:23 +0300
> We try to call free_netvsc_device(net_device) when "net_device" is NULL.
> It leads to an Oops.
>
> Fixes: f90251c8a6d0 ('hyperv: Increase the buffer length for netvsc_channel_cb()')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH net-next] net-timestamp: fix allocation error in test
From: David Miller @ 2014-09-06 0:31 UTC (permalink / raw)
To: willemb; +Cc: netdev, dborkman
In-Reply-To: <1409840145-32723-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Date: Thu, 4 Sep 2014 10:15:45 -0400
> A buffer is incorrectly zeroed to the length of the pointer. If
> cfg_payload_len < sizeof(void *) this can overwrites unrelated memory.
> The buffer contents are never read, so no need to zero.
>
> Fixes: 8fe2f761cae9 ("net-timestamp: expand documentation")
>
> Reported-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] be2net: Learn and program mac to avoid packet replication in nPAR mode.
From: David Miller @ 2014-09-06 0:34 UTC (permalink / raw)
To: VenkatKumar.Duvvuru; +Cc: netdev
In-Reply-To: <206ffa9c-915e-4a1e-affe-68616cbef2f8@CMEXHTCAS1.ad.emulex.com>
From: Venkat Duvvuru <VenkatKumar.Duvvuru@Emulex.com>
Date: Thu, 4 Sep 2014 20:00:59 +0530
> In a multi-channel setup, when an interface (channel/partition) is used
> by a bridge or ovs, it is placed in promiscuous mode and the MAC addresses
> of the VMs attached to the bridge are not configured on the base interface.
> As a result of that, when a packet arrives to the port with
> virtual machine's mac address, the card cannot determine which ring to
> send the packet to, so replicates the packet on all the PFs of that port,
> hence resulting in wastage of PCI bandwidth and CPU cycles. Packet replication
> is also considered security risk as it can cause packets to reach an undesired VM.
>
> This patch will help solve the problem by learning the mac address and
> programming it in the adapter. This patch also unlearns the MAC, if the MAC is
> moved out of the machine or if the MAC is inactive for more than 5 minutes.
>
> Signed-off-by: Venkat Duvvuru <VenkatKumar.Duvvuru@Emulex.com>
This is non-trivial overhead to add to the fast paths of your primary
packet input and output paths.
I think you need to find a different solution to this problem.
^ permalink raw reply
* Re: [PATCH/v2] net: treewide: Fix typo found in DocBook/networking.xml
From: David Miller @ 2014-09-06 0:35 UTC (permalink / raw)
To: standby24x7; +Cc: linux-kernel, rdunlap, netdev, linux-doc, trivial
In-Reply-To: <1409841876-26567-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Thu, 4 Sep 2014 23:44:36 +0900
> This patch fix spelling typo found in DocBook/networking.xml.
> It is because the neworking.xml is generated from comments
> in the source, I have to fix typo in comments within the source.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: harden fnhe_hashfun()
From: David Miller @ 2014-09-06 0:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell
In-Reply-To: <1409844091.26422.123.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 04 Sep 2014 08:21:31 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Lets make this hash function a bit secure, as ICMP attacks are still
> in the wild.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] Series short description
From: David Miller @ 2014-09-06 0:44 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, richardcochran, willemb
In-Reply-To: <20140904172906.7702.87598.stgit@ahduyck-bv4.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Thu, 04 Sep 2014 13:30:29 -0400
> This change makes it so that the core path for the phy timestamping logic
> is shared between skb_tx_tstamp and skb_complete_tx_timestamp. In addition
> it provides a means of using the same skb clone type path in non phy
> timestamping drivers.
>
> The main motivation for this is to enable non-phy drivers to be able to
> manipulate tx timestamp skbs for such things as putting them in lists or
> setting aside buffer in the context block.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] Drop get_headlen functions in favor of generic function
From: David Miller @ 2014-09-06 0:47 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, eric.dumazet, jeffrey.t.kirsher
In-Reply-To: <20140905231807.2035.33588.stgit@ahduyck-bv4.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 05 Sep 2014 19:20:12 -0400
> This series replaces the igb_get_headlen and ixgbe_get_headlen functions
> with a generic function named eth_get_headlen.
>
> I have done some performance testing on ixgbe with 258 byte frames since
> the calls are only used on frames larger than 256 bytes and have seen no
> significant difference in CPU utilization.
>
> v2: renamed __skb_get_poff to skb_get_poff
> renamed ___skb_get_poff to __skb_get_poff
Nice work, series applied, thanks Alex.
^ permalink raw reply
* Re: [PATCH net-next 0/2] tcp: deduplicate TCP_SKB_CB(skb)->when
From: David Miller @ 2014-09-06 0:49 UTC (permalink / raw)
To: edumazet; +Cc: netdev, ycheng, ncardwell
In-Reply-To: <1409956413-29472-1-git-send-email-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 5 Sep 2014 15:33:31 -0700
> TCP_SKB_CB(skb)->when has different meaning in output and input paths.
>
> In output path, it contains a timestamp.
> In input path, it contains an ISN, chosen by tcp_timewait_state_process()
>
> Its usage in output path is obsolete after usec timestamping.
> Lets simplify and clean this.
Nice cleanup, applied, thanks Eric.
^ permalink raw reply
* Re: [RFC net-next 1/5] bonding: 3ad: use curr_slave_lock instead of bond->lock
From: Jay Vosburgh @ 2014-09-06 1:08 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, vfalico, andy, davem
In-Reply-To: <540A247A.60202@redhat.com>
Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>On 09/05/2014 10:37 PM, Jay Vosburgh wrote:
>> Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>>
>>> In 3ad mode the only syncing needed by bond->lock is for the wq
>>> and the recv handler, so change them to use curr_slave_lock.
>>> There're no locking dependencies here as 3ad doesn't use
>>> curr_slave_lock at all.
>>
>> One subtle aspect of the 3ad locking is that it's not really
>> using the "read" property of the read lock with regard to the state
>> machine; it's largely using it as a spin lock, because there is at most
>> one reader and at most one writer in the full state machine code
>> (although there are multiple reader possibilities elsewhere). The code
>> would break if there actually were multiple read-lock holders in the
>> full state machine or aggregator selection logic simultaneously.
>>
>> Because the state machine and incoming LACPDU cases both acquire
>> the read lock for read, there is a separate per-port "state machine"
>> spin lock to protect only the per-port fields that LACPDU and periodic
>> state machine both touch. The incoming LACPDU case doesn't call into
>> the full state machine, only the RX processing which can't go into agg
>> selection, so this works.
>>
>> The agg selection can be entered via the unbind path or the
>> periodic state machine (and only these two paths), and relies on the
>> "one reader max" usage of the read lock to mutex the code paths that may
>> enter agg selection.
>>
>> I suspect that what 3ad may need is a spin lock, not a read
>> lock, because the multiple reader property isn't really being utilized;
>> the incoming LACPDU and periodic state machine both acquire the read
>> lock for read, but then acquire a second per-port spin lock. If the
>> "big" (bond->lock currently) lock is a spin lock, then the per-port
>> state machine lock is unnecessary, as the only purpose of the per-port
>> lock is to mutex the one case that does have multiple readers.
>>
>> In actual practice I doubt there are multiple simultaneous
>> readers very often; the periodic machine runs every 100 ms, but LACPDUs
>> arrive for each port either every second or every 30 seconds (depending
>> on admin configuration).
>>
>> Since contention on these locks is generally low, we're probably
>> better off in the long run with something simpler to understand.
>>
>> So, what I'm kind of saying here is that this patch isn't a bad
>> first step, but at least for the 3ad case, removal of the bond->lock
>> itself doesn't really simplify the locking as much as could be done.
>>
>> Thoughts?
>>
>> -J
>>
>>
>
>Hi Jay,
>That is a very good point, my main idea was to protect __bond_release_one
>and the machine handler otherwise I'd have removed it altogether. I know
>that this doesn't improve on the 3ad situation, I did it mostly to get rid
>of bond->lock first. Going with a spinlock certainly makes sense there as
>we don't spend much time inside and the contention is not high as you said
>and would simplify the 3ad code so I like it :-)
>I will include it in my bond-locking todo list and will post a follow-up
>once I've cleared the details up as I'm speaking from the top of my head
>right now, but first I'd like to clean the current lock use especially with
>regard to curr_slave_lock and bring it to the necessary minimum. In the
>long run I think that we either might be able to remove curr_slave_lock
>completely or at least reduce it to ~ 3 places and with the spinlock that
>you suggested here, we'll be definitely able to remove it from the 3ad code.
I looked into curr_slave_lock some time ago, and as I recall
there's not much it really protects that's not also covered by RTNL,
since changes to the active slave are all happening under RTNL these
days. And that was before the RCU conversion; with the current code,
I'm not sure the curr_slave_lock is providing much mutexing beyond what
we get from RTNL.
There are a couple of special cases, like the TLB rebalance in
bond_alb_monitor, but that happens once every 10 seconds, and could just
grab RTNL for this bit:
if (slave == rcu_access_pointer(bond->curr_active_slave)) {
SLAVE_TLB_INFO(slave).load =
bond_info->unbalanced_load /
BOND_TLB_REBALANCE_INTERVAL;
bond_info->unbalanced_load = 0;
the "unbalanced_load," now that I'm looking at it, might already
have some race problems since it's now updated outside of bonding locks
in bond_do_alb_xmit. It'll probably race with multiple bond_do_alb_xmit
functions running simultaneously as well as the tx rebalance in
bond_alb_monitor. I think the worst that will happen is that the tx
traffic load is distributed suboptimally for 10 seconds.
The rlb_clear_slave case that acquires curr_slave_lock already
also has RTNL, so I'm not sure that removing the curr_slave_lock will
have any impact there, either. Many of the other curr_slave_lock
holders bounce the curr_slave_lock to call into net/core functions (set
promisc, change MAC, etc), so there's already reliance on RTNL.
Separately, it also might be possible to combine the various
per-mode special locks internally into a generic "mode lock" so the alb
and rlb hashtbl lock and the 802.3ad state machine lock could be a
single "bond->mode_lock" that mutexes whatever special sauce the active
mode needs protected. Not sure if that's worth the trouble or not, but
it seems plausible at first glance.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* [PATCH net-next] mlx4: only pull headers into skb head
From: Eric Dumazet @ 2014-09-06 1:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Amir Vadai
From: Eric Dumazet <edumazet@google.com>
Use the new fancy eth_get_headlen() to pull exactly the headers
into skb->head.
This speeds up GRE traffic (or more generally tunneled traffuc),
as GRO can aggregate up to 17 MSS per GRO packet instead of 8.
(Pulling too much data was forcing GRO to keep 2 frags per MSS)
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index b7da466a20d8..14686b6f4bc5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -588,6 +588,8 @@ static struct sk_buff *mlx4_en_rx_skb(struct mlx4_en_priv *priv,
skb_copy_to_linear_data(skb, va, length);
skb->tail += length;
} else {
+ unsigned int pull_len;
+
/* Move relevant fragments to skb */
used_frags = mlx4_en_complete_rx_desc(priv, rx_desc, frags,
skb, length);
@@ -597,16 +599,17 @@ static struct sk_buff *mlx4_en_rx_skb(struct mlx4_en_priv *priv,
}
skb_shinfo(skb)->nr_frags = used_frags;
+ pull_len = eth_get_headlen(va, SMALL_PACKET_SIZE);
/* Copy headers into the skb linear buffer */
- memcpy(skb->data, va, HEADER_COPY_SIZE);
- skb->tail += HEADER_COPY_SIZE;
+ memcpy(skb->data, va, pull_len);
+ skb->tail += pull_len;
/* Skip headers in first fragment */
- skb_shinfo(skb)->frags[0].page_offset += HEADER_COPY_SIZE;
+ skb_shinfo(skb)->frags[0].page_offset += pull_len;
/* Adjust size of first fragment */
- skb_frag_size_sub(&skb_shinfo(skb)->frags[0], HEADER_COPY_SIZE);
- skb->data_len = length - HEADER_COPY_SIZE;
+ skb_frag_size_sub(&skb_shinfo(skb)->frags[0], pull_len);
+ skb->data_len = length - pull_len;
}
return skb;
}
^ permalink raw reply related
* Re: [PATCH net-next v2 2/2] enic: Add ethtool support to show classifier filters added by the driver
From: Ben Hutchings @ 2014-09-06 3:01 UTC (permalink / raw)
To: Govindarajulu Varadarajan; +Cc: davem, netdev, ssujith, benve
In-Reply-To: <1405943538-3086-3-git-send-email-_govind@gmx.com>
[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]
On Mon, 2014-07-21 at 17:22 +0530, Govindarajulu Varadarajan wrote:
> This patch impliments ethtool_ops->get_rxnfc() to display the classifier
> filter added by the driver.
[...]
ARFS and ethtool RXNFC are two different interfaces for setting filters
and they shouldn't be confused with each other.
In the sfc driver, I made the filters inserted through each interface
invisible from the other. The mlx4_en driver also appears to keep the
two sets of filters separate.
I can see that it is useful to be able to find out which filters have
been inserted through ARFS, but it should be possible to distinguish
them from those inserted through RXNFC. Please don't include those
filters when ETHTOOL_GRXCLSRLCNT or ETHTOOL_GRXCLSRLALL are used.
Either add new command numbers for getting ARFS filters (the same
structures will do), or define some kind of extension flag for this
purpose.
Ben.
--
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
- Carolyn Scheppner
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net] cnic : Cleanup CONFIG_IPV6 & VLAN check
From: David Miller @ 2014-09-06 3:47 UTC (permalink / raw)
To: anish; +Cc: netdev, jitendra.kalsaria, mchan, eddie.wai, randy.dunlap
In-Reply-To: <1409875977-31584-1-git-send-email-anish@chelsio.com>
From: Anish Bhatt <anish@chelsio.com>
Date: Thu, 4 Sep 2014 17:12:57 -0700
> The cnic module needs to ensure that if ipv6 support is compiled as a module,
> then the cnic module cannot be compiled as built-in as it depends on ipv6.
> Made this check cleaner via Kconfig
>
> Use simpler IS_ENABLED for CONFIG_VLAN_8021Q check
>
> Signed-off-by: Anish Bhatt <anish@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v6 4/4] tg3: Fix tx_pending checks for tg3_tso_bug
From: David Miller @ 2014-09-06 4:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: prashant, bpoirier, mchan, netdev, linux-kernel
In-Reply-To: <20140905.171306.1460013939580748402.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 05 Sep 2014 17:13:06 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 05 Sep 2014 17:03:30 -0700
>
>> Instead of this private helper (and pretty limited one btw), we could
>> add a core function, that would build skbs with order-0 fragments.
>>
>> Instead of skb_linearize(), I guess many call sites could instead use
>> this new helper.
>>
>> Because as you said, skb_linearize() of one 64KB GSO packet can ask
>> order-5 allocations, and this generally does not work reliably.
>
> xen-netback could make use of this helper too.
I was curious what it might look like so I cobbled the following
completely untested patch together :-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index da1378a..eba0ad6 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -955,6 +955,67 @@ struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t gfp_mask)
EXPORT_SYMBOL(skb_copy);
/**
+ * skb_copy_pskb - copy sk_buff into a paged skb
+ * @oskb: buffer to copy
+ * @gfp_mask: allocation priority
+ *
+ * Normalize a paged skb into one that maximally uses order
+ * zero pages in it's fragment array. This is used to canonicalize
+ * spaghetti SKBs that use the page array inefficiently (f.e. only
+ * one byte per page frag).
+ */
+
+struct sk_buff *skb_copy_pskb(const struct sk_buff *oskb, gfp_t gfp_mask)
+{
+ unsigned int data_len = oskb->data_len;
+ int offset, npages, i;
+ struct sk_buff *skb;
+
+ npages = (data_len + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
+ if (npages > MAX_SKB_FRAGS)
+ return NULL;
+
+ skb = __alloc_skb(skb_end_offset(oskb), gfp_mask,
+ skb_alloc_rx_flag(oskb), NUMA_NO_NODE);
+ if (!skb)
+ return NULL;
+
+ skb_reserve(skb, skb_headroom(oskb));
+ skb_put(skb, skb_headlen(oskb));
+ skb_copy_from_linear_data(oskb, skb->data, skb->len);
+
+ copy_skb_header(skb, oskb);
+
+ skb->truesize += data_len;
+ offset = skb_headlen(oskb);
+ for (i = 0; i < npages; i++) {
+ struct page *page = alloc_page(gfp_mask);
+ unsigned int chunk;
+ u8 *vaddr;
+
+ if (!page) {
+ kfree(skb);
+ skb = NULL;
+ break;
+ }
+
+ chunk = min_t(unsigned int, data_len, PAGE_SIZE);
+ skb_fill_page_desc(skb, i, page, 0, chunk);
+
+ vaddr = kmap_atomic(page);
+ skb_copy_bits(oskb, offset, vaddr, chunk);
+ kunmap_atomic(vaddr);
+
+ offset += chunk;
+ data_len -= chunk;
+ skb->data_len += chunk;
+ }
+
+ return skb;
+}
+EXPORT_SYMBOL(skb_copy_pskb);
+
+/**
* __pskb_copy_fclone - create copy of an sk_buff with private head.
* @skb: buffer to copy
* @headroom: headroom of new skb
^ permalink raw reply related
* Re: [patch net-next] bonding: add slave netlink policy and put slave-related ops together
From: David Miller @ 2014-09-06 4:44 UTC (permalink / raw)
To: jiri; +Cc: netdev, j.vosburgh, nikolay, vfalico, andy
In-Reply-To: <1409909794-7664-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 5 Sep 2014 11:36:34 +0200
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] greth: moved TX ring cleaning to NAPI rx poll func
From: David Miller @ 2014-09-06 4:57 UTC (permalink / raw)
To: daniel; +Cc: netdev, software
In-Reply-To: <1409915628-5249-1-git-send-email-daniel@gaisler.com>
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Fri, 5 Sep 2014 13:13:48 +0200
> This patch does not affect the 10/100 GRETH MAC.
>
> Before all GBit GRETH TX descriptor ring cleaning was done in
> start_xmit(), when descriptor list became full it activated
> TX interrupt to start the NAPI rx poll function to do TX ring
> cleaning.
>
> With this patch the TX descriptor ring is always cleaned from
> the NAPI rx poll function, triggered via TX or RX interrupt.
> Otherwise we could end up in TX frames being sent but not
> reported to the stack being sent. On the 10/100 GRETH this
> is not an issue since the SKB is copied&aligned into private
> buffers so that the SKB can be freed directly on start_xmit()
>
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] mISDN: remove DSP_NEVER_DEFINED and adjust code identation
From: David Miller @ 2014-09-06 5:20 UTC (permalink / raw)
To: colin.king; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <1409923571-28627-1-git-send-email-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 5 Sep 2014 14:26:11 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The DSP_NEVER_DEFINED #ifdef is confusing, it slips in an
> extra } which is not required because the previous code is
> indented incorrectly. Correct the identation and remove the
> extraneous DSP_NEVER_DEFINED
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: only pull headers into skb head
From: David Miller @ 2014-09-06 5:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, amirv
In-Reply-To: <1409966985.11872.6.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 05 Sep 2014 18:29:45 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Use the new fancy eth_get_headlen() to pull exactly the headers
> into skb->head.
>
> This speeds up GRE traffic (or more generally tunneled traffuc),
> as GRO can aggregate up to 17 MSS per GRO packet instead of 8.
>
> (Pulling too much data was forcing GRO to keep 2 frags per MSS)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks great, applied, thanks Eric.
^ 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