* [PATCH net 3/5] macsec: don't put a NULL rxsa
From: Sabrina Dubroca @ 2016-04-19 17:36 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa, Johannes Berg, Dan Carpenter,
Sabrina Dubroca
In-Reply-To: <cover.1460967681.git.sd@queasysnail.net>
The "deliver:" path of macsec_handle_frame can be called with
rx_sa == NULL. Check rx_sa != NULL before calling macsec_rxsa_put().
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
drivers/net/macsec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 5f3ea8026074..2a2136b7d324 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -1161,7 +1161,8 @@ deliver:
macsec_extra_len(macsec_skb_cb(skb)->has_sci));
macsec_reset_skb(skb, secy->netdev);
- macsec_rxsa_put(rx_sa);
+ if (rx_sa)
+ macsec_rxsa_put(rx_sa);
count_rx(dev, skb->len);
rcu_read_unlock();
--
2.8.0
^ permalink raw reply related
* [PATCH net 4/5] macsec: fix rx_sa refcounting with decrypt callback
From: Sabrina Dubroca @ 2016-04-19 17:36 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa, Johannes Berg, Dan Carpenter,
Sabrina Dubroca
In-Reply-To: <cover.1460967681.git.sd@queasysnail.net>
The decrypt callback macsec_decrypt_done needs a reference on the rx_sa
and releases it before returning, but macsec_handle_frame already
put that reference after macsec_decrypt returned NULL.
Change macsec_decrypt to return error codes, and use -EINPROGRESS as
an indication that macsec_handle_frame must not release the reference.
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
drivers/net/macsec.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 2a2136b7d324..1fd2b147fda1 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -880,12 +880,12 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
macsec_skb_cb(skb)->valid = false;
skb = skb_share_check(skb, GFP_ATOMIC);
if (!skb)
- return NULL;
+ return ERR_PTR(-ENOMEM);
req = aead_request_alloc(rx_sa->key.tfm, GFP_ATOMIC);
if (!req) {
kfree_skb(skb);
- return NULL;
+ return ERR_PTR(-ENOMEM);
}
hdr = (struct macsec_eth_header *)skb->data;
@@ -905,7 +905,7 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
skb = skb_unshare(skb, GFP_ATOMIC);
if (!skb) {
aead_request_free(req);
- return NULL;
+ return ERR_PTR(-ENOMEM);
}
} else {
/* integrity only: all headers + data authenticated */
@@ -921,14 +921,14 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
dev_hold(dev);
ret = crypto_aead_decrypt(req);
if (ret == -EINPROGRESS) {
- return NULL;
+ return ERR_PTR(ret);
} else if (ret != 0) {
/* decryption/authentication failed
* 10.6 if validateFrames is disabled, deliver anyway
*/
if (ret != -EBADMSG) {
kfree_skb(skb);
- skb = NULL;
+ skb = ERR_PTR(ret);
}
} else {
macsec_skb_cb(skb)->valid = true;
@@ -1146,8 +1146,10 @@ static rx_handler_result_t macsec_handle_frame(struct sk_buff **pskb)
secy->validate_frames != MACSEC_VALIDATE_DISABLED)
skb = macsec_decrypt(skb, dev, rx_sa, sci, secy);
- if (!skb) {
- macsec_rxsa_put(rx_sa);
+ if (IS_ERR(skb)) {
+ /* the decrypt callback needs the reference */
+ if (PTR_ERR(skb) != -EINPROGRESS)
+ macsec_rxsa_put(rx_sa);
rcu_read_unlock();
*pskb = NULL;
return RX_HANDLER_CONSUMED;
--
2.8.0
^ permalink raw reply related
* [PATCH net 5/5] macsec: add consistency check to netlink dumps
From: Sabrina Dubroca @ 2016-04-19 17:36 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa, Johannes Berg, Dan Carpenter,
Sabrina Dubroca
In-Reply-To: <cover.1460967681.git.sd@queasysnail.net>
Use genl_dump_check_consistent in dump_secy.
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
drivers/net/macsec.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 1fd2b147fda1..41fbe556ba6d 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -2271,6 +2271,8 @@ static int dump_secy(struct macsec_secy *secy, struct net_device *dev,
if (!hdr)
return -EMSGSIZE;
+ genl_dump_check_consistent(cb, hdr, &macsec_fam);
+
if (nla_put_u32(skb, MACSEC_ATTR_IFINDEX, dev->ifindex))
goto nla_put_failure;
@@ -2439,6 +2441,8 @@ nla_put_failure:
return -EMSGSIZE;
}
+static int macsec_generation = 1; /* protected by RTNL */
+
static int macsec_dump_txsc(struct sk_buff *skb, struct netlink_callback *cb)
{
struct net *net = sock_net(skb->sk);
@@ -2449,6 +2453,9 @@ static int macsec_dump_txsc(struct sk_buff *skb, struct netlink_callback *cb)
d = 0;
rtnl_lock();
+
+ cb->seq = macsec_generation;
+
for_each_netdev(net, dev) {
struct macsec_secy *secy;
@@ -2920,6 +2927,8 @@ static void macsec_dellink(struct net_device *dev, struct list_head *head)
struct net_device *real_dev = macsec->real_dev;
struct macsec_rxh_data *rxd = macsec_data_rtnl(real_dev);
+ macsec_generation++;
+
unregister_netdevice_queue(dev, head);
list_del_rcu(&macsec->secys);
if (list_empty(&rxd->secys))
@@ -3066,6 +3075,8 @@ static int macsec_newlink(struct net *net, struct net_device *dev,
if (err < 0)
goto del_dev;
+ macsec_generation++;
+
dev_hold(real_dev);
return 0;
--
2.8.0
^ permalink raw reply related
* Re: [PATCH net-next V2 05/11] net/mlx5e: Support RX multi-packet WQE (Striding RQ)
From: Mel Gorman @ 2016-04-19 17:39 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, Saeed Mahameed, Saeed Mahameed, David S. Miller,
Linux Netdev List, Or Gerlitz, Tal Alon, Tariq Toukan,
Eran Ben Elisha, Achiad Shochat, linux-mm
In-Reply-To: <20160419182532.423d3c05@redhat.com>
On Tue, Apr 19, 2016 at 06:25:32PM +0200, Jesper Dangaard Brouer wrote:
> On Mon, 18 Apr 2016 07:17:13 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Mon, 2016-04-18 at 16:05 +0300, Saeed Mahameed wrote:
> > > On Mon, Apr 18, 2016 at 3:48 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > > On Sun, 2016-04-17 at 17:29 -0700, Eric Dumazet wrote:
> > > >
> > > >>
> > > >> If really you need to allocate physically contiguous memory, have you
> > > >> considered converting the order-5 pages into 32 order-0 ones ?
> > > >
> > > > Search for split_page() call sites for examples.
> > > >
> > > >
> > >
> > > Thanks Eric, we are already evaluating split_page as we speak.
> > >
> > > We did look but could not find any specific alloc_pages API that
alloc_pages_exact()
> > > allocates many physically contiguous pages with order0 ! so we assume
> > > it is ok to use split_page.
> >
> > Note: I have no idea of split_page() performance :
>
> Maybe Mel knows?
Irrelevant in comparison to the cost of allocating an order-5 pages if
one is not already available.
> And maybe Mel have an opinion about if this is a good
> or bad approach, e.g. will this approach stress the page allocator in a
> bad way?
>
It'll contend on the zone lock minimally but again, irrelevant in
comparison to having to reclaim/compact an order-5 page if one is not
already free.
It'll appear to work well in benchmarks and then fall apart when the
system is running for long enough.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH net-next 2/8] sfc: batch up RX delivery on EF10
From: Edward Cree @ 2016-04-19 17:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David Miller, Jesper Dangaard Brouer, linux-net-drivers
In-Reply-To: <1461086440.10638.208.camel@edumazet-glaptop3.roam.corp.google.com>
On 19/04/16 18:20, Eric Dumazet wrote:
> It seems all the discussions about fast kernel networking these days is
> adding yet another queues, code duplication and complexity, batches, and
> add latencies, on top of a single NIC RX queue.
>
> Apparently the multiqueue nature of a NIC is obsolete and people want to
> process 10+Mpps on a single queue.
The real goal here is to speed up packet processing generally.
Doing everything on a single queue (and thus a single CPU) is just a
convenient way of measuring that, while making sure performance is limited
by the RX side rather than the TX not being able to generate enough packets
to keep us busy. Similarly, measuring single-byte UDP packet rate with one
CPU running flat-out is easier than measuring CPU usage while receiving
line-rate TCP in 1400-byte chunks.
> We could probably get ~100% improvement in UDP if we really cared, just
> by changing net/ipv[46]/udp.c, not changing other layers.
Well, I don't know how to achieve that, but it sounds like you do, so why
not go ahead and show us ;)
If you submitted a patch series to make UDP twice as fast, I think people
would "really care" about an improvement of that magnitude.
But RX batching should speed up all traffic, not just UDP. Or at least,
that's the theory.
-Ed
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 1/7] tcp: Carry txstamp_ack in tcp_fragment_tstamp
From: Martin KaFai Lau @ 2016-04-19 17:39 UTC (permalink / raw)
To: Soheil Hassas Yeganeh
Cc: netdev, Eric Dumazet, Neal Cardwell, Soheil Hassas Yeganeh,
Willem de Bruijn, Yuchung Cheng, Kernel Team
In-Reply-To: <CACSApvaRU64xz0N8CVdZrQ__i9MS2aAh5X1kKwhjdv3hz-OU9w@mail.gmail.com>
On Tue, Apr 19, 2016 at 01:21:04AM -0400, Soheil Hassas Yeganeh wrote:
> Could you please submit the timestamping patches separately as non RFCs? Thanks!
Agree. I will re-spin.
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 2/7] tcp: Merge tx_flags/tskey/txstamp_ack in tcp_collapse_retrans
From: Soheil Hassas Yeganeh @ 2016-04-19 17:42 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Eric Dumazet, Neal Cardwell, Soheil Hassas Yeganeh,
Willem de Bruijn, Yuchung Cheng, Kernel Team
In-Reply-To: <20160419172837.GA37697@kafai-mba.local>
On Tue, Apr 19, 2016 at 1:28 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> On Tue, Apr 19, 2016 at 01:32:14AM -0400, Soheil Hassas Yeganeh wrote:
>> > + TCP_SKB_CB(skb)->txstamp_ack =
>> > + !!(shinfo->tx_flags & SKBTX_ACK_TSTAMP);
>>
>> Maybe we can skip a conditional jump here (because of !!), by simply
>> using the cached bit in next_skb:
>> TCP_SKB_CB(skb)->txstamp_ack = TCP_SKB_CB(next_skb)->txstamp_ack;
> Recall the tx_flags are merged/combined (and so should be the txstamp_ack).
Oh sure, sorry, I missed an "or":
TCP_SKB_CB(skb)->txstamp_ack |= TCP_SKB_CB(next_skb)->txstamp_ack;
> Would there be a case that TCP_SKB_CB(skb)->txstamp_ack is 1 and
> TCP_SKB_CB(next_skb)->txstamp_ack is 0?
>
> I can change it like the following which may help in showing the intention:
> if (TCP_SKB_CB(next_skb)->txstamp_ack)
> TCP_SKB_CB(skb)->txstamp_ack = 1;
>
> A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
> of redundant but I have not look into the details yet, so not completely
> sure. It wwould be a separate cleanup patch if it is the case.
As Eric mentioned, this is needed to avoid a cache-line miss in
accessing the shared info.
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers: net: cpsw: Prevent NUll pointer dereference with two PHYs
From: Florian Fainelli @ 2016-04-19 17:44 UTC (permalink / raw)
To: David Rivshin (Allworx), Grygorii Strashko, David S. Miller
Cc: Andrew Goodbody, netdev, linux-kernel, linux-omap, mugunthanvnm,
tony, andrew
In-Reply-To: <20160419131443.7a3b3ef7.drivshin.allworx@gmail.com>
On 19/04/16 10:14, David Rivshin (Allworx) wrote:
>> Ah Ok. There are no user of cpsw_platform_data outside of net/ethernet/ti/,
>> so yes, looks like your patch 1 does exactly what's needed.
>
> Given that the v1 of Andrew's patch is already in Dave's net tree, and
> would obviously have many conflicts with mine, how should I proceed?
> Since you already requested Dave revert that patch, should I just wait
> for that to happen and then resubmit my series?
>
> Dave, Does that sound good to you?
At some point, it would be good for the cpsw driver to be moved to the
DSA subsystem, a lot of these tiny little details, like how to attach
the PHY to the internal, external, fixed MDIO bus have been solved
already using standard DT bindings. This leaves you with the fun part:
how to program your switch such that it works in response to the
networking stack sollicitations (bridge, VLAN, ethtool etc.).
--
Florian
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 1/7] tcp: Carry txstamp_ack in tcp_fragment_tstamp
From: Soheil Hassas Yeganeh @ 2016-04-19 17:44 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Eric Dumazet, Neal Cardwell, Soheil Hassas Yeganeh,
Willem de Bruijn, Yuchung Cheng, Kernel Team
In-Reply-To: <20160419173911.GB39131@kafai-mba.local>
On Tue, Apr 19, 2016 at 1:39 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> On Tue, Apr 19, 2016 at 01:21:04AM -0400, Soheil Hassas Yeganeh wrote:
>> Could you please submit the timestamping patches separately as non RFCs? Thanks!
> Agree. I will re-spin.
Great, thank you very much!
^ permalink raw reply
* Re: [PATCH net 1/5] macsec: add missing NULL check after kmalloc
From: Lance Richardson @ 2016-04-19 17:45 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: netdev, Hannes Frederic Sowa, Johannes Berg, Dan Carpenter
In-Reply-To: <c986bb2421c817eeb00416bd2055f69040924af5.1460967681.git.sd@queasysnail.net>
----- Original Message -----
> From: "Sabrina Dubroca" <sd@queasysnail.net>
> To: netdev@vger.kernel.org
> Cc: "Hannes Frederic Sowa" <hannes@stressinduktion.org>, "Johannes Berg" <johannes@sipsolutions.net>, "Dan Carpenter"
> <dan.carpenter@oracle.com>, "Sabrina Dubroca" <sd@queasysnail.net>
> Sent: Tuesday, April 19, 2016 1:36:38 PM
> Subject: [PATCH net 1/5] macsec: add missing NULL check after kmalloc
>
> Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> drivers/net/macsec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
> index 84d3e5ca8817..f691030ee3df 100644
> --- a/drivers/net/macsec.c
> +++ b/drivers/net/macsec.c
> @@ -1622,8 +1622,8 @@ static int macsec_add_rxsa(struct sk_buff *skb, struct
> genl_info *info)
> }
>
> rx_sa = kmalloc(sizeof(*rx_sa), GFP_KERNEL);
> - if (init_rx_sa(rx_sa, nla_data(tb_sa[MACSEC_SA_ATTR_KEY]), secy->key_len,
> - secy->icv_len)) {
> + if (!rx_sa || init_rx_sa(rx_sa, nla_data(tb_sa[MACSEC_SA_ATTR_KEY]),
> + secy->key_len, secy->icv_len)) {
Doesn't this leak rx_sa if kmalloc() succeeds but init_rx_sa fails?
> rtnl_unlock();
> return -ENOMEM;
> }
> --
> 2.8.0
>
>
^ permalink raw reply
* RE: [Intel-wired-lan] i40e error handling LLDP messages from Arista switches
From: Parikh, Neerav @ 2016-04-19 17:53 UTC (permalink / raw)
To: Jeremy Ashton
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
Parikh, Neerav
In-Reply-To: <739353123C992A4C8800D77E20942590905248DF@ORSMSX103.amr.corp.intel.com>
Resending as the original email was sent in HTLM format and hence my reply went in that format
as well; which got rejected by netdev mailer.
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Parikh, Neerav
> Sent: Tuesday, April 19, 2016 10:45 AM
> To: Jeremy Ashton <jeremy.ashton@shopify.com>
> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] i40e error handling LLDP messages from Arista switches
>
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Jeremy Ashton
> > Sent: Tuesday, April 19, 2016 10:26 AM
> > Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> > Subject: [Intel-wired-lan] i40e error handling LLDP messages from Arista switches
> >
> > I have been trying to get pf_ring with zc running on ubuntu 14.04. The thread can be found here:
> >
> > https://github.com/ntop/PF_RING/issues/81
> >
> > Unfortunately it seems there is a bug in i40e which is carried into the code base for i40e_zc.
> >
> > $ modinfo i40e
> > filename: /lib/modules/3.19.0-58-generic/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
> > version: 1.2.2-k
> > license: GPL
> > description: Intel(R) Ethernet Connection XL710 Network Driver
> > author: Intel Corporation, <e1000-devel@lists.sourceforge.net>
> > srcversion: E3DEEE00F49BBFBB8FF33A7
> > alias: pci:v00008086d00001586sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001585sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001584sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001583sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001581sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001580sv*sd*bc*sc*i*
> > alias: pci:v00008086d0000157Fsv*sd*bc*sc*i*
> > alias: pci:v00008086d00001574sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001572sv*sd*bc*sc*i*
> > depends: ptp,vxlan
> > intree: Y
> > vermagic: 3.19.0-58-generic SMP mod_unload modversions
> > signer: Magrathea: Glacier signing key
> > sig_key: DE:B3:43:0A:26:E6:7D:3D:3B:54:B9:DD:13:25:B3:3A:46:B2:F2:DD
> > sig_hashalgo: sha512
> > part: debug:Debug level (0=none,...,16=all) (int)
> >
> >
> > I wonder if someone might offer some insight as to the next steps to debug/resolve this.
> >
> > Cheers.
> >
> > Can you send us the dmesg output after running i40e debugfs commands
> > viz. “dump port”, “llpd get local” , “lldp get remote”, for the port that is showing
> > this behavior? Also, do you happen to know what is the Arista side configuration?
> > This will help us debug better.
> >
> > Thanks,
> > Neerav
^ permalink raw reply
* Re: [PATCHv2] wlcore: spi: add wl18xx support
From: Mark Brown @ 2016-04-19 17:54 UTC (permalink / raw)
To: Reizer, Eyal
Cc: kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
אייל רייזר,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <oe8hqfknrcljrjawnrxlohvr.1461087275186-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Tue, Apr 19, 2016 at 05:38:02PM +0000, Reizer, Eyal wrote:
> Hi Mark,
>
> Hope you can see the attached picture that illustrates what need to sent for sucesfull SPI init.
I think what the picture shows is that you just need to send at least
one byte at the end of the transfer *after* deasserting /CS which is
totally not what I'd have understood from any of the previous
discussion. That is already supported, just send an extra byte using
.cs_change to do what is says.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [RFC PATCH net-next 7/8] net: ipv4: listified version of ip_rcv
From: Eric Dumazet @ 2016-04-19 17:54 UTC (permalink / raw)
To: Edward Cree
Cc: Tom Herbert, Linux Kernel Network Developers, David Miller,
Jesper Dangaard Brouer, linux-net-drivers
In-Reply-To: <57166719.4070209@solarflare.com>
On Tue, 2016-04-19 at 18:12 +0100, Edward Cree wrote:
> I think if we pushed bundled RX all the way up to the TCP layer, it might
> potentially also be faster than GRO, because it avoids the work of
> coalescing superframes; plus going through the GRO callbacks for each
> packet could end up blowing icache in the same way the regular stack does.
> If bundling did prove faster, we could then remove GRO, and overall
> complexity would be _reduced_.
Oh well. You really are coming 8 years too late.
I receive ~40 Gbit on a _single_ TCP flow with GRO, I have no idea what
you expect to get without GRO, but my educated guess is :
It will be horrible, and will add memory overhead. (remember GRO shares
a single sk_buff/head for all the segs)
And as a bonus, GRO works also on forwarding workloads, when this packet
is delivered to another NIC or a virtual device.
Are you claiming TSO is useless ?
It is not because a model works well in some other stack (userspace I
guess), that we have to copy it in linux kernel.
Feel free to experiment things, but if your non GRO solution is slower
than GRO, don't even mention it here.
Remember to test things with a realistic iptables setup.
^ permalink raw reply
* Re: [patch -next] geneve: testing the wrong variable in geneve6_build_skb()
From: Alexander Duyck @ 2016-04-19 17:57 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, Alexander Duyck, Jesse Gross, John W. Linville,
Pravin B Shelar, Jiri Benc, Daniel Borkmann, Tom Herbert, Netdev,
kernel-janitors
In-Reply-To: <20160419143056.GD4876@mwanda>
On Tue, Apr 19, 2016 at 7:30 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> We intended to test "err" and not "skb".
>
> Fixes: aed069df099c ('ip_tunnel_core: iptunnel_handle_offloads returns int and doesn't free skb')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index efbc7ce..512dbe0 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -733,7 +733,7 @@ static int geneve6_build_skb(struct dst_entry *dst, struct sk_buff *skb,
> goto free_dst;
>
> err = udp_tunnel_handle_offloads(skb, udp_sum);
> - if (IS_ERR(skb))
> + if (err)
> goto free_dst;
>
> gnvh = (struct genevehdr *)__skb_push(skb, sizeof(*gnvh) + opt_len);
Yeah, this looks like I missed a spot. Thanks for catching this.
Acked-by: Alexander Duyck <aduyck@mirantis.com>
^ permalink raw reply
* Re: [RFC PATCH net-next 2/8] sfc: batch up RX delivery on EF10
From: Eric Dumazet @ 2016-04-19 18:02 UTC (permalink / raw)
To: Edward Cree
Cc: netdev, David Miller, Jesper Dangaard Brouer, linux-net-drivers
In-Reply-To: <57166E17.6030002@solarflare.com>
On Tue, 2016-04-19 at 18:42 +0100, Edward Cree wrote:
> Well, I don't know how to achieve that, but it sounds like you do, so why
> not go ahead and show us ;)
> If you submitted a patch series to make UDP twice as fast, I think people
> would "really care" about an improvement of that magnitude.
Yes I definitely can do that, but Google uses SO_REUSEPORT so we do not
care at all consuming more cycles, if we still can absorb the load.
Just try it, and you'll reach 10 Mpps just fine.
^ permalink raw reply
* [net-next PATCH 1/2] netdev_features: Fold NETIF_F_ALL_TSO into NETIF_F_GSO_SOFTWARE
From: Alexander Duyck @ 2016-04-19 18:02 UTC (permalink / raw)
To: netdev, davem, alexander.duyck
This patch folds NETIF_F_ALL_TSO into the bitmask for NETIF_F_GSO_SOFTWARE.
The idea is to avoid duplication of defines since the only difference
between the two was the GSO_UDP bit.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
include/linux/netdev_features.h | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 15eb0b12fff9..bc8736266749 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -152,11 +152,6 @@ enum {
#define NETIF_F_GSO_MASK (__NETIF_F_BIT(NETIF_F_GSO_LAST + 1) - \
__NETIF_F_BIT(NETIF_F_GSO_SHIFT))
-/* List of features with software fallbacks. */
-#define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | \
- NETIF_F_TSO_MANGLEID | \
- NETIF_F_TSO6 | NETIF_F_UFO)
-
/* List of IP checksum features. Note that NETIF_F_ HW_CSUM should not be
* set in features when NETIF_F_IP_CSUM or NETIF_F_IPV6_CSUM are set--
* this would be contradictory
@@ -170,6 +165,9 @@ enum {
#define NETIF_F_ALL_FCOE (NETIF_F_FCOE_CRC | NETIF_F_FCOE_MTU | \
NETIF_F_FSO)
+/* List of features with software fallbacks. */
+#define NETIF_F_GSO_SOFTWARE (NETIF_F_ALL_TSO | NETIF_F_UFO)
+
/*
* If one device supports one of these features, then enable them
* for all in netdev_increment_features.
^ permalink raw reply related
* [net-next PATCH 2/2] veth: Update features to include all tunnel GSO types
From: Alexander Duyck @ 2016-04-19 18:02 UTC (permalink / raw)
To: netdev, davem, alexander.duyck
In-Reply-To: <20160419180219.11003.78651.stgit@ahduyck-xeon-server>
This patch adds support for the checksum enabled versions of UDP and GRE
tunnels. With this change we should be able to send and receive GSO frames
of these types over the veth pair without needing to segment the packets.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/veth.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 4f30a6ae50d0..f37a6e61d4ad 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -312,10 +312,9 @@ static const struct net_device_ops veth_netdev_ops = {
.ndo_set_rx_headroom = veth_set_rx_headroom,
};
-#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO | \
- NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
- NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL | \
- NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT | NETIF_F_UFO | \
+#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
+ NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
+ NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ENCAP_ALL | \
NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
^ permalink raw reply related
* Re: [RFC PATCH net-next 7/8] net: ipv4: listified version of ip_rcv
From: Eric Dumazet @ 2016-04-19 18:06 UTC (permalink / raw)
To: Edward Cree
Cc: netdev, David Miller, Jesper Dangaard Brouer, linux-net-drivers
In-Reply-To: <571661E5.7010304@solarflare.com>
On Tue, 2016-04-19 at 17:50 +0100, Edward Cree wrote:
> On 19/04/16 15:50, Eric Dumazet wrote:
> > The main problem in UDP stack today is having to lock the socket because
> > of the dumb forward allocation problem.
> I'm not quite sure what you're referring to here, care to educate me?
This was added for memory accounting, commit
95766fff6b9a78d11fc2d3812dd035381690b55d
TCP stack does not reclaim its forward allocations as aggressively.
(It has a concept of 'memory pressure')
^ permalink raw reply
* [PATCH] drivers: net: cpsw: fix wrong regs access in cpsw_ndo_open
From: Grygorii Strashko @ 2016-04-19 18:09 UTC (permalink / raw)
To: David S. Miller, netdev, Mugunthan V N
Cc: Sekhar Nori, linux-kernel, linux-omap, Grygorii Strashko
The cpsw_ndo_open() could try to access CPSW registers before
calling pm_runtime_get_sync(). This will trigger L3 error:
WARNING: CPU: 0 PID: 21 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x220/0x34c()
44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_FAST (Idle): Data Access in Supervisor mode during Functional access
and CPSW will stop functioning.
Hence, fix it by moving pm_runtime_get_sync() before the first access
to CPSW registers in cpsw_ndo_open().
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 54bcc38..0fa75a8 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1244,12 +1244,12 @@ static int cpsw_ndo_open(struct net_device *ndev)
int i, ret;
u32 reg;
+ pm_runtime_get_sync(&priv->pdev->dev);
+
if (!cpsw_common_res_usage_state(priv))
cpsw_intr_disable(priv);
netif_carrier_off(ndev);
- pm_runtime_get_sync(&priv->pdev->dev);
-
reg = priv->version;
dev_info(priv->dev, "initializing cpsw version %d.%d (%d)\n",
--
2.8.1
^ permalink raw reply related
* Re: [Intel-wired-lan] i40e error handling LLDP messages from Arista switches
From: Jeremy Ashton @ 2016-04-19 18:10 UTC (permalink / raw)
To: Parikh, Neerav; +Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
In-Reply-To: <739353123C992A4C8800D77E2094259090524953@ORSMSX103.amr.corp.intel.com>
So, what commands exactly are you looking to have run? Would packet
capture of the lldp traffic help?
On Tue, Apr 19, 2016 at 1:53 PM, Parikh, Neerav <neerav.parikh@intel.com> wrote:
> Resending as the original email was sent in HTLM format and hence my reply went in that format
> as well; which got rejected by netdev mailer.
>
>> -----Original Message-----
>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Parikh, Neerav
>> Sent: Tuesday, April 19, 2016 10:45 AM
>> To: Jeremy Ashton <jeremy.ashton@shopify.com>
>> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
>> Subject: Re: [Intel-wired-lan] i40e error handling LLDP messages from Arista switches
>>
>> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Jeremy Ashton
>> > Sent: Tuesday, April 19, 2016 10:26 AM
>> > Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
>> > Subject: [Intel-wired-lan] i40e error handling LLDP messages from Arista switches
>> >
>> > I have been trying to get pf_ring with zc running on ubuntu 14.04. The thread can be found here:
>> >
>> > https://github.com/ntop/PF_RING/issues/81
>> >
>> > Unfortunately it seems there is a bug in i40e which is carried into the code base for i40e_zc.
>> >
>> > $ modinfo i40e
>> > filename: /lib/modules/3.19.0-58-generic/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
>> > version: 1.2.2-k
>> > license: GPL
>> > description: Intel(R) Ethernet Connection XL710 Network Driver
>> > author: Intel Corporation, <e1000-devel@lists.sourceforge.net>
>> > srcversion: E3DEEE00F49BBFBB8FF33A7
>> > alias: pci:v00008086d00001586sv*sd*bc*sc*i*
>> > alias: pci:v00008086d00001585sv*sd*bc*sc*i*
>> > alias: pci:v00008086d00001584sv*sd*bc*sc*i*
>> > alias: pci:v00008086d00001583sv*sd*bc*sc*i*
>> > alias: pci:v00008086d00001581sv*sd*bc*sc*i*
>> > alias: pci:v00008086d00001580sv*sd*bc*sc*i*
>> > alias: pci:v00008086d0000157Fsv*sd*bc*sc*i*
>> > alias: pci:v00008086d00001574sv*sd*bc*sc*i*
>> > alias: pci:v00008086d00001572sv*sd*bc*sc*i*
>> > depends: ptp,vxlan
>> > intree: Y
>> > vermagic: 3.19.0-58-generic SMP mod_unload modversions
>> > signer: Magrathea: Glacier signing key
>> > sig_key: DE:B3:43:0A:26:E6:7D:3D:3B:54:B9:DD:13:25:B3:3A:46:B2:F2:DD
>> > sig_hashalgo: sha512
>> > part: debug:Debug level (0=none,...,16=all) (int)
>> >
>> >
>> > I wonder if someone might offer some insight as to the next steps to debug/resolve this.
>> >
>> > Cheers.
>> >
>> > Can you send us the dmesg output after running i40e debugfs commands
>> > viz. “dump port”, “llpd get local” , “lldp get remote”, for the port that is showing
>> > this behavior? Also, do you happen to know what is the Arista side configuration?
>> > This will help us debug better.
>> >
>> > Thanks,
>> > Neerav
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 2/7] tcp: Merge tx_flags/tskey/txstamp_ack in tcp_collapse_retrans
From: Martin KaFai Lau @ 2016-04-19 18:18 UTC (permalink / raw)
To: Eric Dumazet
Cc: Soheil Hassas Yeganeh, netdev, Neal Cardwell,
Soheil Hassas Yeganeh, Willem de Bruijn, Yuchung Cheng,
Kernel Team
In-Reply-To: <CANn89iJ=Kk3oNbkJ4pOg6bnvJFOUjJa6SSem1jb=BOkR0FF=3g@mail.gmail.com>
On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau <kafai@fb.com> wrote:
>
> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
> > of redundant but I have not look into the details yet, so not completely
> > sure. It wwould be a separate cleanup patch if it is the case.
>
> Please read 6b084928baac562ed61866f540a96120e9c9ddb7 changelog ;)
>
> A cache line miss avoidance is critical
I looked at the patch but I probably am missing something :(
Is checking txstamp_ack alone enough and SKBTX_ACK_TSTAMP is not needed
since they are always set together?
^ permalink raw reply
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Christoph Hellwig @ 2016-04-19 18:22 UTC (permalink / raw)
To: Sinan Kaya
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
cov-sgV2jX0FEOL9JmXXK+q4OQ, Yishai Hadas,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1460845412-13120-1-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
What I think we need is something like the patch below. In the long
ru nwe should also kill the mlx4_buf structure which now is pretty
pointless.
---
>From a493881d2a6c90152d3daabb7b6b3afd1d254d78 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Date: Tue, 19 Apr 2016 14:12:14 -0400
Subject: mlx4_en: don't try to split and vmap dma coherent allocations
The memory returned by dma_alloc_coherent is not suitable for calling
virt_to_page on it, as it might for example come from vmap allocator.
Remove the code that calls virt_to_page and vmap on dma coherent
allocations from the mlx4 drivers, and replace them with a single
high-order dma_alloc_coherent call.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reported-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx4/alloc.c | 89 ++++-------------------
drivers/net/ethernet/mellanox/mlx4/en_cq.c | 7 --
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 31 --------
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 8 --
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 9 ---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 -
drivers/net/ethernet/mellanox/mlx4/mr.c | 5 +-
include/linux/mlx4/device.h | 8 +-
8 files changed, 16 insertions(+), 143 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
index 0c51c69..8d15b35 100644
--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
@@ -588,91 +588,30 @@ int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
{
dma_addr_t t;
- if (size <= max_direct) {
- buf->nbufs = 1;
- buf->npages = 1;
- buf->page_shift = get_order(size) + PAGE_SHIFT;
- buf->direct.buf = dma_alloc_coherent(&dev->persist->pdev->dev,
- size, &t, gfp);
- if (!buf->direct.buf)
- return -ENOMEM;
-
- buf->direct.map = t;
-
- while (t & ((1 << buf->page_shift) - 1)) {
- --buf->page_shift;
- buf->npages *= 2;
- }
+ buf->npages = 1;
+ buf->page_shift = get_order(size) + PAGE_SHIFT;
+ buf->direct.buf = dma_alloc_coherent(&dev->persist->pdev->dev,
+ size, &t, gfp);
+ if (!buf->direct.buf)
+ return -ENOMEM;
- memset(buf->direct.buf, 0, size);
- } else {
- int i;
-
- buf->direct.buf = NULL;
- buf->nbufs = (size + PAGE_SIZE - 1) / PAGE_SIZE;
- buf->npages = buf->nbufs;
- buf->page_shift = PAGE_SHIFT;
- buf->page_list = kcalloc(buf->nbufs, sizeof(*buf->page_list),
- gfp);
- if (!buf->page_list)
- return -ENOMEM;
-
- for (i = 0; i < buf->nbufs; ++i) {
- buf->page_list[i].buf =
- dma_alloc_coherent(&dev->persist->pdev->dev,
- PAGE_SIZE,
- &t, gfp);
- if (!buf->page_list[i].buf)
- goto err_free;
-
- buf->page_list[i].map = t;
-
- memset(buf->page_list[i].buf, 0, PAGE_SIZE);
- }
+ buf->direct.map = t;
- if (BITS_PER_LONG == 64) {
- struct page **pages;
- pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
- if (!pages)
- goto err_free;
- for (i = 0; i < buf->nbufs; ++i)
- pages[i] = virt_to_page(buf->page_list[i].buf);
- buf->direct.buf = vmap(pages, buf->nbufs, VM_MAP, PAGE_KERNEL);
- kfree(pages);
- if (!buf->direct.buf)
- goto err_free;
- }
+ while (t & ((1 << buf->page_shift) - 1)) {
+ --buf->page_shift;
+ buf->npages *= 2;
}
+ memset(buf->direct.buf, 0, size);
return 0;
-
-err_free:
- mlx4_buf_free(dev, size, buf);
-
- return -ENOMEM;
}
EXPORT_SYMBOL_GPL(mlx4_buf_alloc);
void mlx4_buf_free(struct mlx4_dev *dev, int size, struct mlx4_buf *buf)
{
- int i;
-
- if (buf->nbufs == 1)
- dma_free_coherent(&dev->persist->pdev->dev, size,
- buf->direct.buf,
- buf->direct.map);
- else {
- if (BITS_PER_LONG == 64)
- vunmap(buf->direct.buf);
-
- for (i = 0; i < buf->nbufs; ++i)
- if (buf->page_list[i].buf)
- dma_free_coherent(&dev->persist->pdev->dev,
- PAGE_SIZE,
- buf->page_list[i].buf,
- buf->page_list[i].map);
- kfree(buf->page_list);
- }
+ dma_free_coherent(&dev->persist->pdev->dev, size,
+ buf->direct.buf,
+ buf->direct.map);
}
EXPORT_SYMBOL_GPL(mlx4_buf_free);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_cq.c b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
index af975a2..16ef8cf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_cq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
@@ -78,17 +78,11 @@ int mlx4_en_create_cq(struct mlx4_en_priv *priv,
if (err)
goto err_cq;
- err = mlx4_en_map_buffer(&cq->wqres.buf);
- if (err)
- goto err_res;
-
cq->buf = (struct mlx4_cqe *)cq->wqres.buf.direct.buf;
*pcq = cq;
return 0;
-err_res:
- mlx4_free_hwq_res(mdev->dev, &cq->wqres, cq->buf_size);
err_cq:
kfree(cq);
*pcq = NULL;
@@ -177,7 +171,6 @@ void mlx4_en_destroy_cq(struct mlx4_en_priv *priv, struct mlx4_en_cq **pcq)
struct mlx4_en_dev *mdev = priv->mdev;
struct mlx4_en_cq *cq = *pcq;
- mlx4_en_unmap_buffer(&cq->wqres.buf);
mlx4_free_hwq_res(mdev->dev, &cq->wqres, cq->buf_size);
if (mlx4_is_eq_vector_valid(mdev->dev, priv->port, cq->vector) &&
cq->is_tx == RX)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_resources.c b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
index 02e925d..a6b0db0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_resources.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
@@ -107,37 +107,6 @@ int mlx4_en_change_mcast_lb(struct mlx4_en_priv *priv, struct mlx4_qp *qp,
return ret;
}
-int mlx4_en_map_buffer(struct mlx4_buf *buf)
-{
- struct page **pages;
- int i;
-
- if (BITS_PER_LONG == 64 || buf->nbufs == 1)
- return 0;
-
- pages = kmalloc(sizeof *pages * buf->nbufs, GFP_KERNEL);
- if (!pages)
- return -ENOMEM;
-
- for (i = 0; i < buf->nbufs; ++i)
- pages[i] = virt_to_page(buf->page_list[i].buf);
-
- buf->direct.buf = vmap(pages, buf->nbufs, VM_MAP, PAGE_KERNEL);
- kfree(pages);
- if (!buf->direct.buf)
- return -ENOMEM;
-
- return 0;
-}
-
-void mlx4_en_unmap_buffer(struct mlx4_buf *buf)
-{
- if (BITS_PER_LONG == 64 || buf->nbufs == 1)
- return;
-
- vunmap(buf->direct.buf);
-}
-
void mlx4_en_sqp_event(struct mlx4_qp *qp, enum mlx4_event event)
{
return;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 86bcfe5..bc6c14a 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -396,11 +396,6 @@ int mlx4_en_create_rx_ring(struct mlx4_en_priv *priv,
if (err)
goto err_info;
- err = mlx4_en_map_buffer(&ring->wqres.buf);
- if (err) {
- en_err(priv, "Failed to map RX buffer\n");
- goto err_hwq;
- }
ring->buf = ring->wqres.buf.direct.buf;
ring->hwtstamp_rx_filter = priv->hwtstamp_config.rx_filter;
@@ -408,8 +403,6 @@ int mlx4_en_create_rx_ring(struct mlx4_en_priv *priv,
*pring = ring;
return 0;
-err_hwq:
- mlx4_free_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
err_info:
vfree(ring->rx_info);
ring->rx_info = NULL;
@@ -513,7 +506,6 @@ void mlx4_en_destroy_rx_ring(struct mlx4_en_priv *priv,
struct mlx4_en_dev *mdev = priv->mdev;
struct mlx4_en_rx_ring *ring = *pring;
- mlx4_en_unmap_buffer(&ring->wqres.buf);
mlx4_free_hwq_res(mdev->dev, &ring->wqres, size * stride + TXBB_SIZE);
vfree(ring->rx_info);
ring->rx_info = NULL;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index c0d7b72..3c6b59c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -101,12 +101,6 @@ int mlx4_en_create_tx_ring(struct mlx4_en_priv *priv,
goto err_bounce;
}
- err = mlx4_en_map_buffer(&ring->wqres.buf);
- if (err) {
- en_err(priv, "Failed to map TX buffer\n");
- goto err_hwq_res;
- }
-
ring->buf = ring->wqres.buf.direct.buf;
en_dbg(DRV, priv, "Allocated TX ring (addr:%p) - buf:%p size:%d buf_size:%d dma:%llx\n",
@@ -155,8 +149,6 @@ int mlx4_en_create_tx_ring(struct mlx4_en_priv *priv,
err_reserve:
mlx4_qp_release_range(mdev->dev, ring->qpn, 1);
err_map:
- mlx4_en_unmap_buffer(&ring->wqres.buf);
-err_hwq_res:
mlx4_free_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
err_bounce:
kfree(ring->bounce_buf);
@@ -182,7 +174,6 @@ void mlx4_en_destroy_tx_ring(struct mlx4_en_priv *priv,
mlx4_qp_remove(mdev->dev, &ring->qp);
mlx4_qp_free(mdev->dev, &ring->qp);
mlx4_qp_release_range(priv->mdev->dev, ring->qpn, 1);
- mlx4_en_unmap_buffer(&ring->wqres.buf);
mlx4_free_hwq_res(mdev->dev, &ring->wqres, ring->buf_size);
kfree(ring->bounce_buf);
ring->bounce_buf = NULL;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index d12ab6a..a70e2d0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -671,8 +671,6 @@ void mlx4_en_fill_qp_context(struct mlx4_en_priv *priv, int size, int stride,
int is_tx, int rss, int qpn, int cqn, int user_prio,
struct mlx4_qp_context *context);
void mlx4_en_sqp_event(struct mlx4_qp *qp, enum mlx4_event event);
-int mlx4_en_map_buffer(struct mlx4_buf *buf);
-void mlx4_en_unmap_buffer(struct mlx4_buf *buf);
int mlx4_en_change_mcast_lb(struct mlx4_en_priv *priv, struct mlx4_qp *qp,
int loopback);
void mlx4_en_calc_rx_buf(struct net_device *dev);
diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
index 9319519..b61052f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
@@ -802,10 +802,7 @@ int mlx4_buf_write_mtt(struct mlx4_dev *dev, struct mlx4_mtt *mtt,
return -ENOMEM;
for (i = 0; i < buf->npages; ++i)
- if (buf->nbufs == 1)
- page_list[i] = buf->direct.map + (i << buf->page_shift);
- else
- page_list[i] = buf->page_list[i].map;
+ page_list[i] = buf->direct.map + (i << buf->page_shift);
err = mlx4_write_mtt(dev, mtt, 0, buf->npages, page_list);
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 8541a91..536b547 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -618,8 +618,6 @@ struct mlx4_buf_list {
struct mlx4_buf {
struct mlx4_buf_list direct;
- struct mlx4_buf_list *page_list;
- int nbufs;
int npages;
int page_shift;
};
@@ -1051,11 +1049,7 @@ int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
void mlx4_buf_free(struct mlx4_dev *dev, int size, struct mlx4_buf *buf);
static inline void *mlx4_buf_offset(struct mlx4_buf *buf, int offset)
{
- if (BITS_PER_LONG == 64 || buf->nbufs == 1)
- return buf->direct.buf + offset;
- else
- return buf->page_list[offset >> PAGE_SHIFT].buf +
- (offset & (PAGE_SIZE - 1));
+ return buf->direct.buf + offset;
}
int mlx4_pd_alloc(struct mlx4_dev *dev, u32 *pdn);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: David Miller @ 2016-04-19 18:23 UTC (permalink / raw)
To: johannes
Cc: eric.dumazet, roopa, netdev, jhs, tgraf, nicolas.dichtel,
egrumbach
In-Reply-To: <1461060543.2766.20.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 19 Apr 2016 12:09:03 +0200
> At netconf, we talked about how awkward it can be that one doesn't know
> if an attribute was accepted by the kernel or simply ignored because
> it's not supported (older kernel version).
>
> I considered (and Emmanuel has started to cook up a patch for it)
> adding a flag here meaning "reject if not parsed" (or so).
>
> Now, I realize that with all the existing netlink commands one can't
> actually rely on that (since it requires some infrastructure), but new
> commands in existing families and also entirely new generic netlink
> families would allow let userspace rely on such a thing.
I like this nlattr flag idea, it's opt-in and any tool can be updated
to use the new facility.
I'd be willing the backport the nlattr flag bit change to all stable
releases as well.
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: hide unused tables
From: Jes Sorensen @ 2016-04-19 18:24 UTC (permalink / raw)
To: Kalle Valo
Cc: Arnd Bergmann, Jakub Sitnicki, linux-wireless, netdev,
linux-kernel
In-Reply-To: <87mvopy4dy.fsf@purkki.adurom.net>
Kalle Valo <kvalo@codeaurora.org> writes:
> Jes Sorensen <Jes.Sorensen@redhat.com> writes:
>
>> Arnd Bergmann <arnd@arndb.de> writes:
>>> The references to some arrays in the rtl8xxxu driver were moved inside
>>> of an #ifdef, but the symbols remain outside, resulting in build warnings:
>>>
>>> rtl8xxxu/rtl8xxxu.c:1506:33: error:
>>> 'rtl8188ru_radioa_1t_highpa_table' defined but not used
>>> rtl8xxxu/rtl8xxxu.c:1431:33: error:
>>> 'rtl8192cu_radioa_1t_init_table' defined but not used
>>> rtl8xxxu/rtl8xxxu.c:1407:33: error:
>>> 'rtl8192cu_radiob_2t_init_table' defined but not used
>>> rtl8xxxu/rtl8xxxu.c:1332:33: error:
>>> 'rtl8192cu_radioa_2t_init_table' defined but not used
>>> rtl8xxxu/rtl8xxxu.c:239:35: error: 'rtl8192c_power_base' defined but not used
>>> rtl8xxxu/rtl8xxxu.c:217:35: error: 'rtl8188r_power_base' defined but not used
>>>
>>> This adds an extra #ifdef around them to shut up the warnings.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Fixes: 2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts")
>>> Fixes: 4062b8ffec36 ("rtl8xxxu: Move PHY RF init into device
>>> specific functions")
>>> ---
>>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>
>> I'll apply it to my tree!
>
> Actually I would prefer to apply this directly to wireless-drivers-next
> so that the warnings are quickly fixed.
Thats fine with me, I already applied it here before I started doing any
of the refactoring work, so we should be in sync.
Cheers,
Jes
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 2/7] tcp: Merge tx_flags/tskey/txstamp_ack in tcp_collapse_retrans
From: Soheil Hassas Yeganeh @ 2016-04-19 18:24 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Eric Dumazet, netdev, Neal Cardwell, Soheil Hassas Yeganeh,
Willem de Bruijn, Yuchung Cheng, Kernel Team
In-Reply-To: <20160419181644.GA40600@kafai-mba.local>
On Tue, Apr 19, 2016 at 2:18 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
>> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau <kafai@fb.com> wrote:
>>
>> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
>> > of redundant but I have not look into the details yet, so not completely
>> > sure. It wwould be a separate cleanup patch if it is the case.
>>
>> Please read 6b084928baac562ed61866f540a96120e9c9ddb7 changelog ;)
>>
>> A cache line miss avoidance is critical
> I looked at the patch but I probably am missing something :(
> Is checking txstamp_ack alone enough and SKBTX_ACK_TSTAMP is not needed
> since they are always set together?
That's right, the check on "(shinfo->tx_flags & SKBTX_ACK_TSTAMP)" in
tcp_ack_tstamp() is redundant and I had a patch prepared to remove it.
But I thought it's better to wait for
https://patchwork.ozlabs.org/patch/611938/ to be merged first.
Feel free to remove it in your patches, if you'd prefer that.
^ 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