* Re: [PATCH net 0/3] mlx4 fix for shutdown flow
From: David Miller @ 2016-11-18 18:47 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, saeedm, eugenia
In-Reply-To: <1479397251-6932-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Thu, 17 Nov 2016 17:40:48 +0200
> This patchset fixes an invalid reference to mdev in mlx4 shutdown flow.
>
> In patch 1, we make sure netif_device_detach() is called from shutdown flow only,
> since we want to keep it present during a simple configuration change.
>
> In patches 2 and 3, we add checks that were missing in:
> * dev_get_phys_port_id
> * dev_get_phys_port_name
> We check the presence of the network device before calling the driver's
> callbacks. This already exists for all other ndo's.
>
> Series generated against net commit:
> e5f6f564fd19 bnxt: add a missing rcu synchronization
I don't like where this is going nor the precedence it is setting.
If you are taking the device into a state where it cannot be safely
accessed by ndo operations, then you _MUST_ do whatever is necessary
to make sure the device is unregistered and cannot be found in the
various global lists and tables of network devices.
This is mandatory.
And this is how we must fix these kinds of problems instead of
peppering device presence test all over the place. That will be
error prone and in the long term a huge maintainence burdon.
I'm not applying this series, sorry. You have to fix this properly.
^ permalink raw reply
* [PATCH] liquidio CN23XX: check if PENDING bit is clear using logical and
From: Colin King @ 2016-11-18 18:45 UTC (permalink / raw)
To: Derek Chickles, Satanand Burla, Felix Manlunas, Raghu Vatsavayi,
netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
the mbox state should be bitwise anded rather than logically anded
with OCTEON_MBOX_STATE_RESPONSE_PENDING. Fix this by using the
correct & operator instead of &&.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
index 5309384..73696b42 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
@@ -301,7 +301,7 @@ int octeon_mbox_process_message(struct octeon_mbox *mbox)
sizeof(struct octeon_mbox_cmd));
if (!mbox_cmd.msg.s.resp_needed) {
mbox->state &= ~OCTEON_MBOX_STATE_REQUEST_RECEIVED;
- if (!(mbox->state &&
+ if (!(mbox->state &
OCTEON_MBOX_STATE_RESPONSE_PENDING))
mbox->state = OCTEON_MBOX_STATE_IDLE;
writeq(OCTEON_PFVFSIG, mbox->mbox_read_reg);
--
2.10.2
^ permalink raw reply related
* Re: [PATCH -next] tcp: make undo_cwnd mandatory for congestion modules
From: David Miller @ 2016-11-18 18:43 UTC (permalink / raw)
To: fw; +Cc: netdev, edumazet, ycheng, ncardwell
In-Reply-To: <1479387411-9830-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 17 Nov 2016 13:56:51 +0100
> The undo_cwnd fallback in the stack doubles cwnd based on ssthresh,
> which un-does reno halving behaviour.
>
> It seems more appropriate to let congctl algorithms pair .ssthresh
> and .undo_cwnd properly. Add a 'tcp_reno_undo_cwnd' function and wire it
> up for all congestion algorithms that used to rely on the fallback.
>
> highspeed, illinois, scalable, veno and yeah use 'reno undo' while their
> .ssthresh implementation doesn't halve the slowstart threshold, this
> might point to similar issue as the one fixed for dctcp in
> ce6dd23329b1e ("dctcp: avoid bogus doubling of cwnd after loss").
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
If you really suspect that highspeed et al. need to implement their own
undo_cwnd instead of using the default reno fallback, I would really
rather that this gets either fixed or explicitly marked as likely wrong
(in an "XXX" comment or similar).
Otherwise nobody is going to remember this down the road.
^ permalink raw reply
* Re: [PATCH] net: sky2: Fix shutdown crash
From: David Miller @ 2016-11-18 18:41 UTC (permalink / raw)
To: jeremy.linton; +Cc: netdev, mlindner, stephen, Sudeep.Holla
In-Reply-To: <1479395665-27784-1-git-send-email-jeremy.linton@arm.com>
From: Jeremy Linton <jeremy.linton@arm.com>
Date: Thu, 17 Nov 2016 09:14:25 -0600
> The sky2 frequently crashes during machine shutdown with:
>
> sky2_get_stats+0x60/0x3d8 [sky2]
> dev_get_stats+0x68/0xd8
> rtnl_fill_stats+0x54/0x140
> rtnl_fill_ifinfo+0x46c/0xc68
> rtmsg_ifinfo_build_skb+0x7c/0xf0
> rtmsg_ifinfo.part.22+0x3c/0x70
> rtmsg_ifinfo+0x50/0x5c
> netdev_state_change+0x4c/0x58
> linkwatch_do_dev+0x50/0x88
> __linkwatch_run_queue+0x104/0x1a4
> linkwatch_event+0x30/0x3c
> process_one_work+0x140/0x3e0
> worker_thread+0x60/0x44c
> kthread+0xdc/0xf0
> ret_from_fork+0x10/0x50
>
> This is caused by the sky2 being called after it has been shutdown.
> A previous thread about this can be found here:
>
> https://lkml.org/lkml/2016/4/12/410
>
> An alternative fix is to assure that IFF_UP gets cleared by
> calling dev_close() during shutdown. This is similar to what the
> bnx2/tg3/xgene and maybe others are doing to assure that the driver
> isn't being called following _shutdown().
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Bjorn Andersson @ 2016-11-18 18:35 UTC (permalink / raw)
To: Kalle Valo
Cc: Eugene Krasnikov, Kalle Valo, Andy Gross, wcn36xx, linux-wireless,
netdev, linux-kernel, linux-arm-msm
In-Reply-To: <a4095c49fe5a42c4a405b1faf6c0f3b7@euamsexm01a.eu.qualcomm.com>
On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
> Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> > The correct include file for getting errno constants and ERR_PTR() is
> > linux/err.h, rather than linux/errno.h, so fix the include.
> >
> > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled smem_state")
> > Acked-by: Andy Gross <andy.gross@linaro.org>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> For some reason this fails to compile now. Can you take a look, please?
>
> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> 5 patches set to Changes Requested.
>
> 9429045 [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
> 9429047 [v5,2/5] wcn36xx: Transition driver to SMD client
This patch was updated with the necessary depends in Kconfig to catch
this exact issue and when I pull in your .config (which has QCOM_SMD=n,
QCOM_WCNSS_CTRL=n and WCN36XX=y) I can build this just fine.
I've tested the various combinations and it seems to work fine. Do you
have any other patches in your tree? Any stale objects?
Would you mind retesting this, before I invest more time in trying to
reproduce the issue you're seeing?
Regards,
Bjorn
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Eric Dumazet @ 2016-11-18 18:29 UTC (permalink / raw)
To: Joao Pinto
Cc: Florian Fainelli, davem, jeffrey.t.kirsher, jiri, saeedm, idosch,
netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <034e8607-b6d1-02e9-6ec3-fe50f1bd51c8@synopsys.com>
On Fri, 2016-11-18 at 16:40 +0000, Joao Pinto wrote:
> help a lot, thank you!
> lets start working then :)
Please read this very useful document first, so that you can avoid
common mistakes ;)
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
Thanks
^ permalink raw reply
* Re: [PATCH v8 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs
From: Pablo Neira Ayuso @ 2016-11-18 17:44 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Mack, htejun-b10kYP2dOMg, daniel-FeC+5ew28dpmcu3hnIyYJQ,
ast-b10kYP2dOMg, davem-fT/PcQaiUtIeIZ0/mPfg9Q, kafai-b10kYP2dOMg,
fw-HFFVJYpyMKqzQB+pC5nmwQ, harald-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, sargun-GaZTRHToo+CzQB+pC5nmwQ,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118171715.GA56632-+o4/htvd0TDFYCXBM6kdu7fOX0fSgVTm@public.gmane.org>
On Fri, Nov 18, 2016 at 09:17:18AM -0800, Alexei Starovoitov wrote:
> On Fri, Nov 18, 2016 at 01:37:32PM +0100, Pablo Neira Ayuso wrote:
> > On Thu, Nov 17, 2016 at 07:27:08PM +0100, Daniel Mack wrote:
> > [...]
> > > @@ -312,6 +314,12 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> > > skb->dev = dev;
> > > skb->protocol = htons(ETH_P_IP);
> > >
> > > + ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
> > > + if (ret) {
> > > + kfree_skb(skb);
> > > + return ret;
> > > + }
> > > +
> > > /*
> > > * Multicasts are looped back for other local users
> > > */
> > > @@ -364,12 +372,19 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> > > int ip_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> > > {
> > > struct net_device *dev = skb_dst(skb)->dev;
> > > + int ret;
> > >
> > > IP_UPD_PO_STATS(net, IPSTATS_MIB_OUT, skb->len);
> > >
> > > skb->dev = dev;
> > > skb->protocol = htons(ETH_P_IP);
> > >
> > > + ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
> > > + if (ret) {
> > > + kfree_skb(skb);
> > > + return ret;
> > > + }
> > > +
> > > return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING,
> > > net, sk, skb, NULL, dev,
> > > ip_finish_output,
> >
> > Please, place this after the netfilter hook.
> >
> > Since this new hook may mangle output packets, any mangling
> > potentially interfers and breaks conntrack.
>
> actually this hook cannot mangle the packets, so no conntrack
> concerns. Also this was brought up by Lorenzo earlier and consensus
> was that it's cleaner to leave it in this order.
Not yet probably, but this could be used to implement snat at some
point, you have potentially the infrastructure to do so in place
already.
> My reply:
> http://www.spinics.net/lists/cgroups/msg16675.html
> and Daniel's:
> http://www.spinics.net/lists/cgroups/msg16677.html
> and the rest of that thread.
Please place this afterwards since I don't want to update Netfilter
documentation to indicate that there is a new spot to debug before
POSTROUTING that may drop packets. People are used to debugging things
in a certain way, if packets are dropped after POSTROUTING, then
netfilter tracing will indicate the packet has successfully left our
framework and people will notice that packets are dropped somewhere
else, so they have a clue probably is this new layer.
Actually I remember you mentioned in a previous email that this hook
can be placed anywhere, and that they don't really need a fixed
location, if so, then it should not be much of a problem to change
this.
I can live with this new scenario where the kernel becomes a place
where everyone can push bpf blobs everywhere and your "code decides"
submission policy if others do as well, even if I frankly don't like
it. No problem. But please don't use the word "consensus" to justify
this, because this was not exactly what it was shown during Netconf.
So just send a v9 with this change I'm requesting and you have my word
I will not intefer anymore on this submission.
Thank you.
^ permalink raw reply
* Re: [PATCH] netns: fix get_net_ns_by_fd(int pid) typo
From: Rami Rosen @ 2016-11-18 17:40 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: Netdev, David S. Miller
In-Reply-To: <1479462106-28529-1-git-send-email-stefanha@redhat.com>
On 18 November 2016 at 11:41, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> The argument to get_net_ns_by_fd() is a /proc/$PID/ns/net file
> descriptor not a pid. Fix the typo.
>
Acked-by: Rami Rosen <roszenrami@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next] amd-xgbe: Update connection validation for backplane mode
From: David Miller @ 2016-11-18 17:28 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev
In-Reply-To: <20161117144337.5714.57761.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Thu, 17 Nov 2016 08:43:37 -0600
> Update the connection type enumeration for backplane mode and return
> an error when there is a mismatch between the mode and the connection
> type.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v8 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs
From: Alexei Starovoitov @ 2016-11-18 17:17 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Daniel Mack, htejun-b10kYP2dOMg, daniel-FeC+5ew28dpmcu3hnIyYJQ,
ast-b10kYP2dOMg, davem-fT/PcQaiUtIeIZ0/mPfg9Q, kafai-b10kYP2dOMg,
fw-HFFVJYpyMKqzQB+pC5nmwQ, harald-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, sargun-GaZTRHToo+CzQB+pC5nmwQ,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118123732.GA10400@salvia>
On Fri, Nov 18, 2016 at 01:37:32PM +0100, Pablo Neira Ayuso wrote:
> On Thu, Nov 17, 2016 at 07:27:08PM +0100, Daniel Mack wrote:
> [...]
> > @@ -312,6 +314,12 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> > skb->dev = dev;
> > skb->protocol = htons(ETH_P_IP);
> >
> > + ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
> > + if (ret) {
> > + kfree_skb(skb);
> > + return ret;
> > + }
> > +
> > /*
> > * Multicasts are looped back for other local users
> > */
> > @@ -364,12 +372,19 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> > int ip_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> > {
> > struct net_device *dev = skb_dst(skb)->dev;
> > + int ret;
> >
> > IP_UPD_PO_STATS(net, IPSTATS_MIB_OUT, skb->len);
> >
> > skb->dev = dev;
> > skb->protocol = htons(ETH_P_IP);
> >
> > + ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
> > + if (ret) {
> > + kfree_skb(skb);
> > + return ret;
> > + }
> > +
> > return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING,
> > net, sk, skb, NULL, dev,
> > ip_finish_output,
>
> Please, place this after the netfilter hook.
>
> Since this new hook may mangle output packets, any mangling
> potentially interfers and breaks conntrack.
actually this hook cannot mangle the packets, so no conntrack concerns.
Also this was brought up by Lorenzo earlier
and consensus was that it's cleaner to leave it in this order.
My reply:
http://www.spinics.net/lists/cgroups/msg16675.html
and Daniel's:
http://www.spinics.net/lists/cgroups/msg16677.html
and the rest of that thread.
Thanks
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] Adding PHY-Tunables and downshift support
From: David Miller @ 2016-11-18 17:14 UTC (permalink / raw)
To: allan.nielsen; +Cc: netdev, andrew, f.fainelli, raju.lakkaraju
In-Reply-To: <1479384444-31122-1-git-send-email-allan.nielsen@microsemi.com>
From: "Allan W. Nielsen" <allan.nielsen@microsemi.com>
Date: Thu, 17 Nov 2016 13:07:19 +0100
> This series add support for PHY tunables, and uses this facility to
> configure downshifting. The downshifting mechanism is implemented for MSCC
> phys.
Series applied, thanks.
^ permalink raw reply
* Re: Netperf UDP issue with connected sockets
From: Jesper Dangaard Brouer @ 2016-11-18 17:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Rick Jones, netdev, Saeed Mahameed, Tariq Toukan, brouer
In-Reply-To: <1479419042.8455.280.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, 17 Nov 2016 13:44:02 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2016-11-17 at 22:19 +0100, Jesper Dangaard Brouer wrote:
>
> >
> > Maybe you can share your udp flood "udpsnd" program source?
>
> Very ugly. This is based on what I wrote when tracking the UDP v6
> checksum bug (4f2e4ad56a65f3b7d64c258e373cb71e8d2499f4 net: mangle zero
> checksum in skb_checksum_help()), because netperf sends the same message
> over and over...
Thanks a lot, hope you don't mind; I added the code to my github repo:
https://github.com/netoptimizer/network-testing/blob/master/src/udp_snd.c
So I identified the difference, and reason behind the route lookups.
Your program is using send() and I was using sendmsg(). Given
udp_flood is designed to test different calls, I simply added --send as
a new possibility.
https://github.com/netoptimizer/network-testing/commit/16166c2cd1fa8
If I use --write instead, then I can also avoid the fib_table_lookup
and __ip_route_output_key_hash calls.
> Use -d 2 to remove the ip_idents_reserve() overhead.
#define IP_PMTUDISC_DO 2 /* Always DF */
Added a --pmtu option to my udp_flood program
https://github.com/netoptimizer/network-testing/commit/23a78caf4bb5b
> #define _GNU_SOURCE
>
> #include <errno.h>
> #include <error.h>
> #include <linux/errqueue.h>
> #include <netinet/in.h>
> #include <sched.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/time.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <unistd.h>
>
> char buffer[1400];
>
> int main(int argc, char** argv) {
> int fd, i;
> struct sockaddr_in6 addr;
> char *host = "2002:af6:798::1";
> int family = AF_INET6;
> int discover = -1;
>
> while ((i = getopt(argc, argv, "4H:d:")) != -1) {
> switch (i) {
> case 'H': host = optarg; break;
> case '4': family = AF_INET; break;
> case 'd': discover = atoi(optarg); break;
> }
> }
> fd = socket(family, SOCK_DGRAM, 0);
> if (fd < 0)
> error(1, errno, "failed to create socket");
> if (discover != -1)
> setsockopt(fd, SOL_IP, IP_MTU_DISCOVER,
> &discover, sizeof(discover));
>
> memset(&addr, 0, sizeof(addr));
> if (family == AF_INET6) {
> addr.sin6_family = AF_INET6;
> addr.sin6_port = htons(9);
> inet_pton(family, host, (void *)&addr.sin6_addr.s6_addr);
> } else {
> struct sockaddr_in *in = (struct sockaddr_in *)&addr;
> in->sin_family = family;
> in->sin_port = htons(9);
> inet_pton(family, host, &in->sin_addr);
> }
> connect(fd, (struct sockaddr *)&addr,
> (family == AF_INET6) ? sizeof(addr) :
> sizeof(struct sockaddr_in));
> memset(buffer, 1, 1400);
> for (i = 0; i < 655360000; i++) {
> memcpy(buffer, &i, sizeof(i));
> send(fd, buffer, 100 + rand() % 200, 0);
Using send() avoids the fib_table_lookup, on a connected UDP socket.
> }
> return 0;
> }
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next V2 0/8] Mellanox 100G mlx5 update 2016-11-15
From: David Miller @ 2016-11-18 17:09 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <1479383162-3432-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 17 Nov 2016 13:45:54 +0200
> This series contains four humble mlx5 features.
>
> From Gal,
> - Add the support for PCIe statistics and expose them in ethtool
>
> From Huy,
> - Add the support for port module events reporting and statistics
> - Add the support for driver version setting into FW (for display purposes only)
>
> From Mohamad,
> - Extended the command interface cache flexibility
>
> This series was generated against commit
> 6a02f5eb6a8a ("Merge branch 'mlxsw-i2c")
>
> V2:
> - Changed plain "unsigned" to "unsigned int"
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/5] sfc: Firmware-Assisted TSO version 2
From: David Miller @ 2016-11-18 17:03 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, bkenward, netdev
In-Reply-To: <ae6b02ca-9a0b-7072-6914-294fc9adb684@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Thu, 17 Nov 2016 10:49:42 +0000
> The firmware on 8000 series SFC NICs supports a new TSO API ("FATSOv2"), and
> 7000 series NICs will also support this in an imminent release. This series
> adds driver support for this TSO implementation.
> The series also removes SWTSO, as it's now equivalent to GSO. This does not
> actually remove very much code, because SWTSO was grotesquely intertwingled
> with FATSOv1, which will also be removed once 7000 series supports FATSOv2.
Series applied, thanks.
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-18 16:40 UTC (permalink / raw)
To: Florian Fainelli, Joao Pinto, davem, jeffrey.t.kirsher, jiri,
saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <a4bb3828-3aa5-1e80-f57e-ad9a94a681b3@gmail.com>
On 18-11-2016 16:35, Florian Fainelli wrote:
>
>
> On 11/18/2016 08:31 AM, Joao Pinto wrote:
>> Hi Florian,
>>
>> On 18-11-2016 14:53, Florian Fainelli wrote:
>>> On November 18, 2016 4:28:30 AM PST, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>>
snip (...)
>>>> I would also gladly be available to be its maintainer if you agree with
>>>> it.
>>>
>>> Since you have both the hardware and a clear todo list for this driver, start submitting patches, get them included in David's tree and over time chances are that you will become the maintainer, either explicitly by adding an entry in the MAINTAINERS file or just by consistently contributing to this area.
>>
>> Thanks for the feedback.
>>
>> So I found 2 suitable git trees:
>> a) kernel/git/davem/net.git
>> b) kernel/git/davem/net-next.git
>>
>> We should submit to net.git correct? The net-next.git is a tree with selected
>> patches for upstream only?
>
> net-next.git is the git tree where new features/enhancements can be
> submitted, while net.git is for bug fixes. Unless you absolutely need
> to, it is common practice to avoid having changes in net-next.git depend
> on net.git and vice versa.
>
> Hope this helps.
>
help a lot, thank you!
lets start working then :)
Thanks,
Joao
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Florian Fainelli @ 2016-11-18 16:35 UTC (permalink / raw)
To: Joao Pinto, davem, jeffrey.t.kirsher, jiri, saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <fbf4263b-2b08-611d-f9cb-1f09c6f91117@synopsys.com>
On 11/18/2016 08:31 AM, Joao Pinto wrote:
> Hi Florian,
>
> On 18-11-2016 14:53, Florian Fainelli wrote:
>> On November 18, 2016 4:28:30 AM PST, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>
>>> Dear all,
>>>
>>> My name is Joao Pinto and I work at Synopsys.
>>> I am a kernel developer with special focus in mainline collaboration,
>>> both Linux
>>> and Buildroot. I was recently named one of the maintainers of the PCIe
>>> Designware core driver and I was the author of the Designware UFS
>>> driver stack.
>>>
>>> I am sending you this e-mail because you were the suggested contacts
>> >from the
>>> get_maintainers script concerning Ethernet drivers :).
>>>
>>> Currently I have the task to work on the mainline Ethernet QoS driver
>>> in which
>>> you are the author. The work would consist of the following:
>>>
>>> a) Separate the current driver in a Core driver (common ops) + platform
>>> glue
>>> driver + pci glue driver
>>> b) Add features that are currently only available internally
>>> c) Add specific phy support using the PHY framework
>>>
>>> I would also gladly be available to be its maintainer if you agree with
>>> it.
>>
>> Since you have both the hardware and a clear todo list for this driver, start submitting patches, get them included in David's tree and over time chances are that you will become the maintainer, either explicitly by adding an entry in the MAINTAINERS file or just by consistently contributing to this area.
>
> Thanks for the feedback.
>
> So I found 2 suitable git trees:
> a) kernel/git/davem/net.git
> b) kernel/git/davem/net-next.git
>
> We should submit to net.git correct? The net-next.git is a tree with selected
> patches for upstream only?
net-next.git is the git tree where new features/enhancements can be
submitted, while net.git is for bug fixes. Unless you absolutely need
to, it is common practice to avoid having changes in net-next.git depend
on net.git and vice versa.
Hope this helps.
--
Florian
^ permalink raw reply
* Re: [net-next] af_packet: Use virtio_net_hdr_to_skb().
From: David Miller @ 2016-11-18 16:35 UTC (permalink / raw)
To: jarno; +Cc: netdev
In-Reply-To: <1479348402-126248-1-git-send-email-jarno@ovn.org>
From: Jarno Rajahalme <jarno@ovn.org>
Date: Wed, 16 Nov 2016 18:06:42 -0800
> Use the common virtio_net_hdr_to_skb() instead of open coding it.
> Other call sites were changed by commit fd2a0437dc, but this one was
> missed, maybe because it is split in two parts of the source code.
>
> Also fix other call sites to be more uniform.
>
> Fixes: fd2a0437dc ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
> Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
This patch is doing many more things that just this.
Do not mix unrelated changes together:
> @@ -821,9 +821,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> if (iov_iter_count(iter) < vnet_hdr_len)
> return -EINVAL;
>
> - ret = virtio_net_hdr_from_skb(skb, &vnet_hdr,
> - macvtap_is_little_endian(q));
> - if (ret)
> + if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
> + macvtap_is_little_endian(q)))
> BUG();
>
> if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
This has nothing to do with modifying code to use vrtio_net_hdr_to_skb(), it
doesn't belong in this patch.
> @@ -1361,15 +1360,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> }
>
> if (vnet_hdr_sz) {
> - struct virtio_net_hdr gso = { 0 }; /* no info leak */
> - int ret;
> -
> + struct virtio_net_hdr gso;
This is _extremely_ opaque. The initializer is trying to prevent kernel memory
info leaks onto the network or into user space.
Maybe this transformation is valid but:
1) YOU DON'T EVEN MENTION IT IN YOUR COMMIT MESSAGE.
2) It's unrelated to this specific change, therefore it belongs in
a separate change.
3) You don't explain that it is a valid transformation, not why.
It is extremely disappointing to catch unrelated, potentially far
reaching things embedded in a patch when I review it.
Please do not ever do this.
> @@ -98,4 +98,4 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> return 0;
> }
>
> -#endif /* _LINUX_VIRTIO_BYTEORDER */
> +#endif /* _LINUX_VIRTIO_NET_H */
Another unrelated change.
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 11db0d6..09abb88 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1971,8 +1971,6 @@ static unsigned int run_filter(struct sk_buff *skb,
> static int __packet_rcv_vnet(const struct sk_buff *skb,
> struct virtio_net_hdr *vnet_hdr)
> {
> - *vnet_hdr = (const struct virtio_net_hdr) { 0 };
> -
There is no way this belongs in this patch, and again you do not explain
why removing this initializer is valid.
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-18 16:31 UTC (permalink / raw)
To: Florian Fainelli, Joao Pinto, davem, jeffrey.t.kirsher, jiri,
saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <771E7B93-5AB6-4F2B-8DEB-58DDB6A96D13@gmail.com>
Hi Florian,
On 18-11-2016 14:53, Florian Fainelli wrote:
> On November 18, 2016 4:28:30 AM PST, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>
>> Dear all,
>>
>> My name is Joao Pinto and I work at Synopsys.
>> I am a kernel developer with special focus in mainline collaboration,
>> both Linux
>> and Buildroot. I was recently named one of the maintainers of the PCIe
>> Designware core driver and I was the author of the Designware UFS
>> driver stack.
>>
>> I am sending you this e-mail because you were the suggested contacts
>>from the
>> get_maintainers script concerning Ethernet drivers :).
>>
>> Currently I have the task to work on the mainline Ethernet QoS driver
>> in which
>> you are the author. The work would consist of the following:
>>
>> a) Separate the current driver in a Core driver (common ops) + platform
>> glue
>> driver + pci glue driver
>> b) Add features that are currently only available internally
>> c) Add specific phy support using the PHY framework
>>
>> I would also gladly be available to be its maintainer if you agree with
>> it.
>
> Since you have both the hardware and a clear todo list for this driver, start submitting patches, get them included in David's tree and over time chances are that you will become the maintainer, either explicitly by adding an entry in the MAINTAINERS file or just by consistently contributing to this area.
Thanks for the feedback.
So I found 2 suitable git trees:
a) kernel/git/davem/net.git
b) kernel/git/davem/net-next.git
We should submit to net.git correct? The net-next.git is a tree with selected
patches for upstream only?
>
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Florian Fainelli @ 2016-11-18 14:53 UTC (permalink / raw)
To: Joao Pinto, davem, jeffrey.t.kirsher, jiri, saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <cbe5f79b-53a4-e116-1e09-bc975a66a8ca@synopsys.com>
On November 18, 2016 4:28:30 AM PST, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>
>Dear all,
>
>My name is Joao Pinto and I work at Synopsys.
>I am a kernel developer with special focus in mainline collaboration,
>both Linux
>and Buildroot. I was recently named one of the maintainers of the PCIe
>Designware core driver and I was the author of the Designware UFS
>driver stack.
>
>I am sending you this e-mail because you were the suggested contacts
>from the
>get_maintainers script concerning Ethernet drivers :).
>
>Currently I have the task to work on the mainline Ethernet QoS driver
>in which
>you are the author. The work would consist of the following:
>
>a) Separate the current driver in a Core driver (common ops) + platform
>glue
>driver + pci glue driver
>b) Add features that are currently only available internally
>c) Add specific phy support using the PHY framework
>
>I would also gladly be available to be its maintainer if you agree with
>it.
Since you have both the hardware and a clear todo list for this driver, start submitting patches, get them included in David's tree and over time chances are that you will become the maintainer, either explicitly by adding an entry in the MAINTAINERS file or just by consistently contributing to this area.
--
Florian
^ permalink raw reply
* Re: [mm PATCH v3 00/23] Add support for DMA writable pages being writable by the network stack
From: Alexander Duyck @ 2016-11-18 16:10 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Netdev, linux-kernel@vger.kernel.org, Alexander Duyck
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>
On Thu, Nov 10, 2016 at 3:34 AM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
> The first 19 patches in the set add support for the DMA attribute
> DMA_ATTR_SKIP_CPU_SYNC on multiple platforms/architectures. This is needed
> so that we can flag the calls to dma_map/unmap_page so that we do not
> invalidate cache lines that do not currently belong to the device. Instead
> we have to take care of this in the driver via a call to
> sync_single_range_for_cpu prior to freeing the Rx page.
>
> Patch 20 adds support for dma_map_page_attrs and dma_unmap_page_attrs so
> that we can unmap and map a page using the DMA_ATTR_SKIP_CPU_SYNC
> attribute.
>
> Patch 21 adds support for freeing a page that has multiple references being
> held by a single caller. This way we can free page fragments that were
> allocated by a given driver.
>
> The last 2 patches use these updates in the igb driver, and lay the
> groundwork to allow for us to reimplement the use of build_skb.
>
> v1: Minor fixes based on issues found by kernel build bot
> Few minor changes for issues found on code review
> Added Acked-by for patches that were acked and not changed
>
> v2: Added a few more Acked-by
> Submitting patches to mm instead of net-next
>
> v3: Added Acked-by for PowerPC architecture
> Dropped first 3 patches which were accepted into swiotlb tree
> Dropped comments describing swiotlb changes.
>
> ---
>
> Alexander Duyck (23):
> arch/arc: Add option to skip sync on DMA mapping
> arch/arm: Add option to skip sync on DMA map and unmap
> arch/avr32: Add option to skip sync on DMA map
> arch/blackfin: Add option to skip sync on DMA map
> arch/c6x: Add option to skip sync on DMA map and unmap
> arch/frv: Add option to skip sync on DMA map
> arch/hexagon: Add option to skip DMA sync as a part of mapping
> arch/m68k: Add option to skip DMA sync as a part of mapping
> arch/metag: Add option to skip DMA sync as a part of map and unmap
> arch/microblaze: Add option to skip DMA sync as a part of map and unmap
> arch/mips: Add option to skip DMA sync as a part of map and unmap
> arch/nios2: Add option to skip DMA sync as a part of map and unmap
> arch/openrisc: Add option to skip DMA sync as a part of mapping
> arch/parisc: Add option to skip DMA sync as a part of map and unmap
> arch/powerpc: Add option to skip DMA sync as a part of mapping
> arch/sh: Add option to skip DMA sync as a part of mapping
> arch/sparc: Add option to skip DMA sync as a part of map and unmap
> arch/tile: Add option to skip DMA sync as a part of map and unmap
> arch/xtensa: Add option to skip DMA sync as a part of mapping
> dma: Add calls for dma_map_page_attrs and dma_unmap_page_attrs
> mm: Add support for releasing multiple instances of a page
> igb: Update driver to make use of DMA_ATTR_SKIP_CPU_SYNC
> igb: Update code to better handle incrementing page count
>
>
> arch/arc/mm/dma.c | 5 ++
> arch/arm/common/dmabounce.c | 16 ++++--
> arch/avr32/mm/dma-coherent.c | 7 ++-
> arch/blackfin/kernel/dma-mapping.c | 8 +++
> arch/c6x/kernel/dma.c | 14 ++++-
> arch/frv/mb93090-mb00/pci-dma-nommu.c | 14 ++++-
> arch/frv/mb93090-mb00/pci-dma.c | 9 +++
> arch/hexagon/kernel/dma.c | 6 ++
> arch/m68k/kernel/dma.c | 8 +++
> arch/metag/kernel/dma.c | 16 +++++-
> arch/microblaze/kernel/dma.c | 10 +++-
> arch/mips/loongson64/common/dma-swiotlb.c | 2 -
> arch/mips/mm/dma-default.c | 8 ++-
> arch/nios2/mm/dma-mapping.c | 26 +++++++---
> arch/openrisc/kernel/dma.c | 3 +
> arch/parisc/kernel/pci-dma.c | 20 ++++++--
> arch/powerpc/kernel/dma.c | 9 +++
> arch/sh/kernel/dma-nommu.c | 7 ++-
> arch/sparc/kernel/iommu.c | 4 +-
> arch/sparc/kernel/ioport.c | 4 +-
> arch/tile/kernel/pci-dma.c | 12 ++++-
> arch/xtensa/kernel/pci-dma.c | 7 ++-
> drivers/net/ethernet/intel/igb/igb.h | 7 ++-
> drivers/net/ethernet/intel/igb/igb_main.c | 77 +++++++++++++++++++----------
> include/linux/dma-mapping.h | 20 +++++---
> include/linux/gfp.h | 2 +
> mm/page_alloc.c | 14 +++++
> 27 files changed, 246 insertions(+), 89 deletions(-)
>
So I am just wondering if I need to resubmit this to pick up the new
"Acked-by"s or if I should just wait?
As I said in the description my hope is to get this into the -mm tree
and I am not familiar with what the process is for being accepted
there.
Thanks.
- Alex
--
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: [PATCH] netns: make struct pernet_operations::id unsigned int
From: David Miller @ 2016-11-18 16:08 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20161117015821.GA1200@avx2>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Thu, 17 Nov 2016 04:58:21 +0300
> Make struct pernet_operations::id unsigned.
...
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] mlxsw: switchib: add MLXSW_PCI dependency
From: Arnd Bergmann @ 2016-11-18 16:01 UTC (permalink / raw)
To: Jiri Pirko, Ido Schimmel
Cc: Arnd Bergmann, David S. Miller, Ivan Vecera, Elad Raz, netdev,
linux-kernel
The newly added switchib driver fails to link if MLXSW_PCI=m:
drivers/net/ethernet/mellanox/mlxsw/mlxsw_switchib.o: In function^Cmlxsw_sib_module_exit':
switchib.c:(.exit.text+0x8): undefined reference to `mlxsw_pci_driver_unregister'
switchib.c:(.exit.text+0x10): undefined reference to `mlxsw_pci_driver_unregister'
drivers/net/ethernet/mellanox/mlxsw/mlxsw_switchib.o: In function `mlxsw_sib_module_init':
switchib.c:(.init.text+0x28): undefined reference to `mlxsw_pci_driver_register'
switchib.c:(.init.text+0x38): undefined reference to `mlxsw_pci_driver_register'
switchib.c:(.init.text+0x48): undefined reference to `mlxsw_pci_driver_unregister'
The other two such sub-drivers have a dependency, so add the same one
here. In theory we could allow this driver if MLXSW_PCI is disabled,
but it's probably not worth it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/Kconfig b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
index bac2e5e826e2..49237a24605e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
@@ -31,7 +31,7 @@ config MLXSW_PCI
config MLXSW_SWITCHIB
tristate "Mellanox Technologies SwitchIB and SwitchIB-2 support"
- depends on MLXSW_CORE && NET_SWITCHDEV
+ depends on MLXSW_CORE && MLXSW_PCI && NET_SWITCHDEV
default m
---help---
This driver supports Mellanox Technologies SwitchIB and SwitchIB-2
--
2.9.0
^ permalink raw reply related
* Re: [net-next PATCH v2] net: dummy: Introduce dummy virtual functions
From: Phil Sutter @ 2016-11-18 15:59 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, Linux Netdev List, Sabrina Dubroca
In-Reply-To: <CAJ3xEMhG4Eeh6pwY2Uq_KxmuHJb9-xYYkr4Ps_kQWwEXeB9Sbg@mail.gmail.com>
Hi,
On Fri, Nov 18, 2016 at 12:04:14AM +0200, Or Gerlitz wrote:
> On Mon, Nov 14, 2016 at 3:02 PM, Phil Sutter <phil@nwl.cc> wrote:
>
> > Due to the assumption that all PFs are PCI devices, this implementation
> > is not completely straightforward: In order to allow for
> > rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> > attached to the dummy netdev. This has to happen at the right spot so
> > register_netdevice() does not get confused. This patch abuses
> > ndo_fix_features callback for that. In ndo_uninit callback, the fake
> > parent is removed again for the same purpose.
>
> So you did some mimic-ing of PCI interface, how do you let the user to
> config the number of VFs? though a module param? why? if the module
> param only serves to say how many VF the device supports, maybe
> support the maximum possible by PCI spec and skip the module param?
Yes, this is controlled via module parameter. But it doesn't say how
much is supported but rather how many dummy VFs are to be created for
each dummy interface.
> > +module_param(num_vfs, int, 0);
> > +MODULE_PARM_DESC(num_vfs, "Number of dummy VFs per dummy device");
> > +
>
> > @@ -190,6 +382,7 @@ static int __init dummy_init_one(void)
> > err = register_netdevice(dev_dummy);
> > if (err < 0)
> > goto err;
> > +
> > return 0;
>
> nit, remove this added blank line..
Oh yes, thanks. Spontaneous reviewer's blindness. :)
The implementation is problematic in another aspect though: Upon reboot,
it seems like no netdev ops are being called but the fake PCI parent's
kobject is being freed which does not work (and leads to an oops).
Cheers, Phil
^ permalink raw reply
* Re: [PATCH net-next] udp: enable busy polling for all sockets
From: David Miller @ 2016-11-18 15:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, willemb
In-Reply-To: <1479316242.8455.213.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Nov 2016 09:10:42 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> UDP busy polling is restricted to connected UDP sockets.
>
> This is because sk_busy_loop() only takes care of one NAPI context.
>
> There are cases where it could be extended.
>
> 1) Some hosts receive traffic on a single NIC, with one RX queue.
>
> 2) Some applications use SO_REUSEPORT and associated BPF filter
> to split the incoming traffic on one UDP socket per RX
> queue/thread/cpu
>
> 3) Some UDP sockets are used to send/receive traffic for one flow, but
> they do not bother with connect()
>
>
> This patch records the napi_id of first received skb, giving more
> reach to busy polling.
>
> Tested:
>
> lpaa23:~# echo 70 >/proc/sys/net/core/busy_read
> lpaa24:~# echo 70 >/proc/sys/net/core/busy_read
>
> lpaa23:~# for f in `seq 1 10`; do ./super_netperf 1 -H lpaa24 -t UDP_RR -l 5; done
>
> Before patch :
> 27867 28870 37324 41060 41215
> 36764 36838 44455 41282 43843
> After patch :
> 73920 73213 70147 74845 71697
> 68315 68028 75219 70082 73707
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v3 3/5] net: asix: Fix AX88772x resume failures
From: Jon Hunter @ 2016-11-18 15:09 UTC (permalink / raw)
To: allan, robert.foss, freddy, Dean_Jenkins, Mark_Craske, davem,
ivecera, john.stultz, vpalatin, stephen, grundler, changchias,
andrew, tremyfr, colin.king, linux-usb, netdev, linux-kernel,
vpalatin
In-Reply-To: <010d01d23e5b$d8993130$89cb9390$@asix.com.tw>
Hi Allan,
On 14/11/16 09:45, ASIX_Allan [Office] wrote:
> Hi Jon,
>
> Please help to double check if the USB host controller of your Terga
> platform had been powered OFF while running the ax88772_suspend() routine or
> not?
Sorry for the delay. Today I set up a local board to reproduce this on
and was able to recreate the same problem. The Tegra xhci driver does
not power off during suspend and simply calls xhci_suspend(). I also
checked vbus to see if it was turning off but it is not. Furthermore I
don't see a new USB device detected after the error and so I don't see
any evidence that it ever disconnects.
Cheers
Jon
--
nvpublic
^ 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