* Re: [PATCHv2 net-next 1/6] sctp: add sctp_info dump api for sctp_diag
From: Eric Dumazet @ 2016-04-09 17:21 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Xin Long, network dev, linux-sctp, Marcelo Ricardo Leitner,
Vlad Yasevich, daniel, davem
In-Reply-To: <57091D90.4030905@mojatatu.com>
On Sat, 2016-04-09 at 11:19 -0400, Jamal Hadi Salim wrote:
> On 16-04-09 01:16 AM, Eric Dumazet wrote:
>
> >
> > Lots of holes in this structure...
> >
> >
>
>
> I may have mentioned to you that there is 8 bit hole in tcp_info too ;->
> (above tcpi_rto). Adding an 8 bit explicit pad seems useful
> since it is already in the wild. I was going to send the patch after
> netdev11 but forgot.
Well, once a hole is there, nothing we can do really, because of
compatibility with old kernels / old binaries.
But when a _new_ structure is defined, this is the time where we can ask
for doing sensible things ;)
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: use napi_complete_done()
From: Petri Gynther @ 2016-04-09 17:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Florian Fainelli
In-Reply-To: <1460178400.6473.469.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Apr 8, 2016 at 10:06 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> By using napi_complete_done(), we allow fine tuning
> of /sys/class/net/ethX/gro_flush_timeout for higher GRO aggregation
> efficiency for a Gbit NIC.
>
> Check commit 24d2e4a50737 ("tg3: use napi_complete_done()") for details.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Petri Gynther <pgynther@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Petri Gynther <pgynther@google.com>
> ---
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index f7b42b9fc979..e823013d3125 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1735,7 +1735,7 @@ static int bcmgenet_rx_poll(struct napi_struct *napi, int budget)
> work_done = bcmgenet_desc_rx(ring, budget);
>
> if (work_done < budget) {
> - napi_complete(napi);
> + napi_complete_done(napi, work_done);
> ring->int_enable(ring);
> }
>
>
>
^ permalink raw reply
* Re: [PATCHv2 net-next 4/6] sctp: add the sctp_diag.c file
From: Eric Dumazet @ 2016-04-09 17:23 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Vlad Yasevich,
daniel, davem
In-Reply-To: <CADvbK_dZDDCpEm-RF_Zv3Xq6kvnfGnnk822cON5rUJPo-R8Y4Q@mail.gmail.com>
On Sat, 2016-04-09 at 23:40 +0800, Xin Long wrote:
> you meant we can remove it here ?
> yes, it seems similar with INET_DIAG_SKMEMINFO.
> but I do not know if userpace may use INET_DIAG_MEMINFO now.
>
You are adding new features here. No problem of legacy code.
Anyway, as I said you really need to reuse code, not copy paste please.
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: use __napi_schedule_irqoff()
From: Petri Gynther @ 2016-04-09 17:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Fainelli, David Miller, netdev, opendmb
In-Reply-To: <1460179856.6473.482.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Apr 8, 2016 at 10:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
>
> bcmgenet_isr1() and bcmgenet_isr0() run in hard irq context,
> we do not need to block irq again.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Petri Gynther <pgynther@google.com>
> ---
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index f7b42b9fc979..4367d561a12e 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -2493,7 +2493,7 @@ static irqreturn_t bcmgenet_isr1(int irq, void *dev_id)
>
> if (likely(napi_schedule_prep(&rx_ring->napi))) {
> rx_ring->int_disable(rx_ring);
> - __napi_schedule(&rx_ring->napi);
> + __napi_schedule_irqoff(&rx_ring->napi);
> }
> }
>
> @@ -2506,7 +2506,7 @@ static irqreturn_t bcmgenet_isr1(int irq, void *dev_id)
>
> if (likely(napi_schedule_prep(&tx_ring->napi))) {
> tx_ring->int_disable(tx_ring);
> - __napi_schedule(&tx_ring->napi);
> + __napi_schedule_irqoff(&tx_ring->napi);
> }
> }
>
> @@ -2536,7 +2536,7 @@ static irqreturn_t bcmgenet_isr0(int irq, void *dev_id)
>
> if (likely(napi_schedule_prep(&rx_ring->napi))) {
> rx_ring->int_disable(rx_ring);
> - __napi_schedule(&rx_ring->napi);
> + __napi_schedule_irqoff(&rx_ring->napi);
> }
> }
>
> @@ -2545,7 +2545,7 @@ static irqreturn_t bcmgenet_isr0(int irq, void *dev_id)
>
> if (likely(napi_schedule_prep(&tx_ring->napi))) {
> tx_ring->int_disable(tx_ring);
> - __napi_schedule(&tx_ring->napi);
> + __napi_schedule_irqoff(&tx_ring->napi);
> }
> }
>
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] bpf: add PHYS_DEV prog type for early driver filter
From: Alexei Starovoitov @ 2016-04-09 17:26 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Tom Herbert, Jesper Dangaard Brouer, Brenden Blanco,
David S. Miller, Linux Kernel Network Developers, Or Gerlitz,
Daniel Borkmann, Eric Dumazet, Edward Cree, john fastabend,
Thomas Graf, Johannes Berg, eranlinuxmellanox, Lorenzo Colitti,
linux-mm
In-Reply-To: <57091FCE.50104@mojatatu.com>
On Sat, Apr 09, 2016 at 11:29:18AM -0400, Jamal Hadi Salim wrote:
> On 16-04-09 07:29 AM, Tom Herbert wrote:
>
> >+1. Forwarding which will be a common application almost always
> >requires modification (decrement TTL), and header data split has
> >always been a weak feature since the device has to have some arbitrary
> >rules about what headers needs to be split out (either implements
> >protocol specific parsing or some fixed length).
>
> Then this is sensible. I was cruising the threads and
> confused by your earlier emails Tom because you talked
> about XPS etc. It sounded like the idea evolved into putting
> the whole freaking stack on bpf.
yeah, no stack, no queues in bpf.
> If this is _forwarding only_ it maybe useful to look at
> Alexey's old code in particular the DMA bits;
> he built his own lookup algorithm but sounds like bpf is
> a much better fit today.
a link to these old bits?
Just to be clear: this rfc is not the only thing we're considering.
In particular huawei guys did a monster effort to improve performance
in this area as well. We'll try to blend all the code together and
pick what's the best.
--
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 v2 5/5] Add sample for adding simple drop program to link
From: Jamal Hadi Salim @ 2016-04-09 17:27 UTC (permalink / raw)
To: Brenden Blanco
Cc: davem, netdev, tom, alexei.starovoitov, ogerlitz, daniel, brouer,
eric.dumazet, ecree, john.fastabend, tgraf, johannes,
eranlinuxmellanox, lorenzo
In-Reply-To: <20160409164308.GA5750@gmail.com>
On 16-04-09 12:43 PM, Brenden Blanco wrote:
> On Sat, Apr 09, 2016 at 10:48:05AM -0400, Jamal Hadi Salim wrote:
>> Ok, sorry - should have looked this far before sending earlier email.
>> So when you run concurently you see about 5Mpps per core but if you
>> shoot all traffic at a single core you see 20Mpps?
> No, only sender is multiple, receiver is still single core. The flow is
> the same in all 4 of the send threads. Note that only ksoftirqd/6 is
> active.
Got it.
The sender was limited to the 20Mpps and you are able to keep up
if i understand correctly.
>>
>> Devil's advocate question:
>> If the bottleneck is the driver - is there an advantage in adding the
>> bpf code at all in the driver?
> Only by adding this hook into the driver has it become the bottleneck.
>
> Prior to this, the bottleneck was later in the codepath, primarily in
> allocations.
>
Maybe useful in your commit log to show the prior and after.
Looking at both your and Daniel's profile you show in this email
mlx4_en_process_rx_cq() seems to be where the action is on both, no?
> If a packet is to be dropped, and a determination can be made with fewer
> cpu cycles spent, then there is more time for the goodput.
>
Agreed.
> Beyond that, even if the skb allocation gets 10x or 100x or whatever
> improvement, there is still a non-zero cost associated, and dropping bad
> packets with minimal time spent has value. The same argument holds for
> physical nic forwarding decisions.
>
I always go for the lowest hanging fruit.
It seemed it was the driver path in your case. When we removed
the driver overhead (as demoed at the tc workshop in netdev11) we saw
__netif_receive_skb_core() at the top of the profile.
So in this case seems it was mlx4_en_process_rx_cq() - thats why i
was saying the bottleneck is the driver.
Having said that: I agree that early drop is useful if not for anything
else to avoid the longer code path (but was worried after reading on
thread this was going to get into a messy stack-in-the-driver and i am
not sure it is avoidable either given a new ops interface is showing
up).
>> I am curious than before to see the comparison for the same bpf code
>> running at tc level vs in the driver..
> Here is a perf report for drop in the clsact qdisc with direct-action,
> which Daniel earlier showed to have the best performance to-date. On my
> machine, this gets about 6.5Mpps drop single core. Drop due to failed
> IP lookup (not shown here) is worse @4.5Mpps.
>
Nice.
However, still for this to be orange/orange comparison you have to
run it on the _same receiver machine_ as opposed to Daniel doing
it on his for the one case. And two different kernels booted up
one patched with your changes and another virgin without them.
cheers,
jamal
^ permalink raw reply
* Re: [PATCHv2 net-next 1/6] sctp: add sctp_info dump api for sctp_diag
From: Eric Dumazet @ 2016-04-09 17:29 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Vlad Yasevich,
daniel, davem
In-Reply-To: <CADvbK_dzvjT=pFYP8uRDa8naNWUp+dkUHSVXP+Y8P0U3=nQM8g@mail.gmail.com>
On Sun, 2016-04-10 at 00:10 +0800, Xin Long wrote:
> On Sat, Apr 9, 2016 at 1:19 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Sat, 2016-04-09 at 12:53 +0800, Xin Long wrote:
> >> sctp_diag will dump some important details of sctp's assoc or ep, we use
> >> sctp_info to describe them, sctp_get_sctp_info to get them, and export
> >> it to sctp_diag.ko.
> >>
> >
> >
> >> +int sctp_get_sctp_info(struct sock *sk, struct sctp_association *asoc,
> >> + struct sctp_info *info)
> >> +{
> >> + struct sctp_transport *prim;
> >> + struct list_head *pos, *temp;
> >> + int mask;
> >> +
> >> + memset(info, 0, sizeof(*info));
> >> + if (!asoc) {
> >> + struct sctp_sock *sp = sctp_sk(sk);
> >> +
> >> + info->sctpi_s_autoclose = sp->autoclose;
> >> + info->sctpi_s_adaptation_ind = sp->adaptation_ind;
> >> + info->sctpi_s_pd_point = sp->pd_point;
> >> + info->sctpi_s_nodelay = sp->nodelay;
> >> + info->sctpi_s_disable_fragments = sp->disable_fragments;
> >> + info->sctpi_s_v4mapped = sp->v4mapped;
> >> + info->sctpi_s_frag_interleave = sp->frag_interleave;
> >> +
> >> + return 0;
> >> + }
> >> +
> >> + info->sctpi_tag = asoc->c.my_vtag;
> >> + info->sctpi_state = asoc->state;
> >> + info->sctpi_rwnd = asoc->a_rwnd;
> >> + info->sctpi_unackdata = asoc->unack_data;
> >> + info->sctpi_penddata = sctp_tsnmap_pending(&asoc->peer.tsn_map);
> >> + info->sctpi_instrms = asoc->c.sinit_max_instreams;
> >> + info->sctpi_outstrms = asoc->c.sinit_num_ostreams;
> >> + list_for_each_safe(pos, temp, &asoc->base.inqueue.in_chunk_list)
> >> + info->sctpi_inqueue++;
> >> + list_for_each_safe(pos, temp, &asoc->outqueue.out_chunk_list)
> >> + info->sctpi_outqueue++;
> >
> > Is this safe ?
> >
> > Do you own the lock on socket or whatever lock protecting this list ?
> >
> there are 2 places will call these codes,
> 1. sctp_diag_dump -> sctp_for_each_transport -> sctp_tsp_dump
> this one will use lock_sock to protect them. I think this one is ok.
>
> 1. sctp_diag_dump_one -> sctp_transport_lookup_process-> sctp_tsp_dump_one
> this one just holds the tsp. and we're using list_for_each_safe here now,
> isn't it enough ?
>
You tell me ;)
For sure in tcp_get_info() the socket is sometimes locked, and sometimes
is not locked, depending on the caller.
So we had to use only lockless accesses.
^ permalink raw reply
* Re: [PATCHv2 net-next 1/6] sctp: add sctp_info dump api for sctp_diag
From: Eric Dumazet @ 2016-04-09 17:31 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Vlad Yasevich,
daniel, davem
In-Reply-To: <CADvbK_dzvjT=pFYP8uRDa8naNWUp+dkUHSVXP+Y8P0U3=nQM8g@mail.gmail.com>
On Sun, 2016-04-10 at 00:10 +0800, Xin Long wrote:
> 1. sctp_diag_dump_one -> sctp_transport_lookup_process-> sctp_tsp_dump_one
> this one just holds the tsp. and we're using list_for_each_safe here now,
> isn't it enough ?
list_for_each_safe is 'safe' if you do a list_del() yourself.
It is not safe if other cpus are adding/deleting items in the list while
this thread is iterating it.
^ permalink raw reply
* Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO
From: Alexander Duyck @ 2016-04-09 17:36 UTC (permalink / raw)
To: Jesse Gross
Cc: Alexander Duyck, Herbert Xu, Tom Herbert, Eric Dumazet,
Linux Kernel Network Developers, David Miller
In-Reply-To: <CAEh+42j5_SKku5EWexLi+1Ch4Eu=SoijMGSCYyZAd39GeMq8GQ@mail.gmail.com>
On Sat, Apr 9, 2016 at 8:52 AM, Jesse Gross <jesse@kernel.org> wrote:
> On Fri, Apr 8, 2016 at 7:04 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, Apr 8, 2016 at 2:40 PM, Jesse Gross <jesse@kernel.org> wrote:
>>> Maybe I missed it but I didn't see any checks for the DF bit being set
>>> when we transmit a packet with NETIF_F_TSO_MANGLEID. Even if I am
>>> comfortable mangling my IDs in the DF case, I don't think this would
>>> ever extend to non-DF packets. In the documentation you noted that it
>>> is the driver's responsibility to do this check but I couldn't find it
>>> in either ixgbe or igb. It would also be nice if the core stack could
>>> enforce it somehow as well rather than each driver.
>>
>> Yeah I had glossed over that in the igb and ixgbe patches. A check is
>> only really needed for the incrementing to non-incrementing case and I
>> wasn't sure how common it was to have TCP with an IP header that
>> didn't set the DF bit. In the case of the outer headers igb and ixgbe
>> will increment the IP ID always so we don't have to worry about if DF
>> is set of not there. For the inner headers I had fudged it a bit and
>> didn't add the validation. If needed I can see about adding that
>> shortly.
>
> TCP without the DF bit set is not the default but it is possible (it
> can be enabled by setting /proc/sys/net/ipv4/ip_no_pmtu_disc). I also
> did a quick check of some Internet services and at least some of them
> seem to return TCP without DF, so it's not too rare.
For next version I plan to include a check in netif_skb_features that
will clear NETIF_F_TSO_MANGLEID if the DF bit is not set.
- Alex
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: roopa @ 2016-04-09 18:00 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, davem
In-Reply-To: <5709120D.9010107@mojatatu.com>
On 4/9/16, 7:30 AM, Jamal Hadi Salim wrote:
>
> Thanks for doing the work Roopa and I apologize for late comments
> below:
>
> On 16-04-09 02:38 AM, Roopa Prabhu wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>
>> This patch also allows for af family stats (an example af stats for IPV6
>> is available with the second patch in the series).
>>
>> Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
>> a single interface or all interfaces with NLM_F_DUMP.
>>
>> Future possible new types of stat attributes:
>> - IFLA_MPLS_STATS (nested. for mpls/mdev stats)
>> - IFLA_EXTENDED_STATS (nested. extended software netdev stats like bridge,
>> vlan, vxlan etc)
>> - IFLA_EXTENDED_HW_STATS (nested. extended hardware stats which are
>> available via ethtool today)
>>
>
> I got the extended_hw_stats (which are very common in a lot of ASICS) if
> you mean stats on packet sizes. But would the other extended stats not
> just be per netdev kind specific? We have concept of XSTATS which maybe
> a fit.
This EXTENDED_HW_STATS is for ethtool like extended hw stats. This is keeping in
mind that we want to also move ethtool to netlink in the future and with switchdev
it becomes more necessary that we provide all stats closer to the other netdev stats.
So far hw extended stats have always been available through this separate ethtool
channel. The intent here is to unify the api for extended hw and software only stats.
XSTATS is per netdev can be included as a nested attribute inside IFLA_EXTENDED_STATS
which are per netdev. bridge vlan stats will also fall here.
And this api provides netdev specific stats. We have always mapped all
asic stats to the switch port netdev stats. and this api does not cover the non-netdev specific stats.
If you are for example asking for stats for a hardware offloaded bridge, then yes, they will fall here
and be available on the bridge netdev. For asic stats that don't map to any netdev, devlink will be an
appropriate infrastructure IMO.
I am not sure if I answered your question :).
>
>> This patch also declares a filter mask for all stat attributes.
>> User has to provide a mask of stats attributes to query. This will be
>> specified in a new hdr 'struct if_stats_msg' for stats messages.
>>
>> Without any attributes in the filter_mask, no stats will be returned.
>>
>
> Should such a command then not be rejected with an error code?
Dumps with no data are not rejected with an error code AFAIK. ie they don't return
-ENODATA. This is consistent with all other dumps (unless i missed it).
But, if there is a need for an error code, i can certainly check again.
>> +/* STATS section */
>> +
>> +struct if_stats_msg {
>> + __u8 family;
>> + __u32 ifindex;
>> + __u32 filter_mask;
>> +};
>
> Needs to be 32 bit aligned.
> Do you need 32 bits for the filter mask?
yes, i think we should keep it minimum 32 bits.
> Perhaps a 16bit mask and an 8bit pad for future use.
>
> struct if_stats_msg {
> __u32 ifindex;
> __u16 filter_mask;
> __u8 family;
> __u8 pad; /* future use */
> };
>
> Or you could reverse those (from smallest to largest).
The __u8 family needs to be the first field in the structure and at the first byte in the header data.
hence family is first and i added the others after that. It follows the format for existing such structs (for other message types).
> BTW, any plans to do the cool feature where i inject a timeout period
> and i just get STATS events ;-> The filter struct would have to be more
> sophisticated - user would need to pass a list of ifindices and
> filter_mask as well as timeout.
Yeah i remember :). But deferring it for a later incremental feature. That needs some more thought.
Right now there is an urgent need to get the basic get stats api for a bunch of other stats: mpls, bridge vlan etc.
Because it is not clean to extend the current stats infra part of the link message for this. So trying to get this in first.
And this patchset only adds a handler for RTM_NEWSTATS dump and get stats. Your stats events request should be part of the RTM_NEWSTATS handler and can include other attributes (like timeout) in the future.
Thanks,
Roopa
^ permalink raw reply
* Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO
From: Eric Dumazet @ 2016-04-09 18:02 UTC (permalink / raw)
To: Alexander Duyck
Cc: Jesse Gross, Alexander Duyck, Herbert Xu, Tom Herbert,
Eric Dumazet, Linux Kernel Network Developers, David Miller
In-Reply-To: <CAKgT0UdR863RBgkMMuT=Db1D1YQUpXOFLh6Bz7nVQxoMuDzuzQ@mail.gmail.com>
On Sat, 2016-04-09 at 10:36 -0700, Alexander Duyck wrote:
> For next version I plan to include a check in netif_skb_features that
> will clear NETIF_F_TSO_MANGLEID if the DF bit is not set.
So it looks like we slowly but surely make the whole stack damn slow, to
support some extra features.
How many instructions are needed nowadays for netif_skb_features()
alone ?
More than 120 if I am not mistaken, if we count fast path in
skb_network_protocol()
Note: I have a patch to remove the gso_min_segs thing, currently unused.
2 instructions saved ! Woo-hoo !
^ permalink raw reply
* [PATCH net-next] net: remove netdevice gso_min_segs
From: Eric Dumazet @ 2016-04-09 18:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
After introduction of ndo_features_check(), we believe that very
specific checks for rare features should not be done in core
networking stack.
No driver uses gso_min_segs yet, so we revert this feature and save
few instructions per tx packet in fast path.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/netdevice.h | 4 +---
net/core/dev.c | 3 +--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cb4e508b3f38..dd3391aafa7d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1586,8 +1586,6 @@ enum netdev_priv_flags {
* @gso_max_size: Maximum size of generic segmentation offload
* @gso_max_segs: Maximum number of segments that can be passed to the
* NIC for GSO
- * @gso_min_segs: Minimum number of segments that can be passed to the
- * NIC for GSO
*
* @dcbnl_ops: Data Center Bridging netlink ops
* @num_tc: Number of traffic classes in the net device
@@ -1858,7 +1856,7 @@ struct net_device {
unsigned int gso_max_size;
#define GSO_MAX_SEGS 65535
u16 gso_max_segs;
- u16 gso_min_segs;
+
#ifdef CONFIG_DCB
const struct dcbnl_rtnl_ops *dcbnl_ops;
#endif
diff --git a/net/core/dev.c b/net/core/dev.c
index 273f10d1e306..b75dfdb37422 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2831,7 +2831,7 @@ netdev_features_t netif_skb_features(struct sk_buff *skb)
netdev_features_t features = dev->features;
u16 gso_segs = skb_shinfo(skb)->gso_segs;
- if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs)
+ if (gso_segs > dev->gso_max_segs)
features &= ~NETIF_F_GSO_MASK;
/* If encapsulation offload request, verify we are testing
@@ -7428,7 +7428,6 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
dev->gso_max_size = GSO_MAX_SIZE;
dev->gso_max_segs = GSO_MAX_SEGS;
- dev->gso_min_segs = 0;
INIT_LIST_HEAD(&dev->napi_list);
INIT_LIST_HEAD(&dev->unreg_list);
^ permalink raw reply related
* Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO
From: Alexander Duyck @ 2016-04-09 18:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesse Gross, Alexander Duyck, Herbert Xu, Tom Herbert,
Eric Dumazet, Linux Kernel Network Developers, David Miller
In-Reply-To: <1460224948.6473.511.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, Apr 9, 2016 at 11:02 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2016-04-09 at 10:36 -0700, Alexander Duyck wrote:
>
>> For next version I plan to include a check in netif_skb_features that
>> will clear NETIF_F_TSO_MANGLEID if the DF bit is not set.
>
> So it looks like we slowly but surely make the whole stack damn slow, to
> support some extra features.
>
> How many instructions are needed nowadays for netif_skb_features()
> alone ?
>
> More than 120 if I am not mistaken, if we count fast path in
> skb_network_protocol()
>
> Note: I have a patch to remove the gso_min_segs thing, currently unused.
>
> 2 instructions saved ! Woo-hoo !
I was planning to drop the checks for TSO_MANGLEID and GSO_PARTIAL in
a if statment based on skb_is_gso() since I had both GSO_PARTIAL to
check for as well.
- Alex
^ permalink raw reply
* [git pull] sock_recvmsg() redundant argument
From: Al Viro @ 2016-04-09 20:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Preparation for a bunch of iov_iter stuff; I'm not sure if all of those should
go via net-next (e.g. cifs stuff almost certainly doesn't, etc.), but this
bit is common to all those series and it would be better off in your tree.
sendmsg counterpart was "get rid of the size argument of sock_sendmsg()" and
it went in more than a year ago; this one sat in my private queue since
then.
The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:
Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-davem
for you to fetch changes up to 2da62906b1e298695e1bb725927041cd59942c98:
[net] drop 'size' argument of sock_recvmsg() (2016-03-28 13:57:51 -0400)
----------------------------------------------------------------
Al Viro (1):
[net] drop 'size' argument of sock_recvmsg()
drivers/target/iscsi/iscsi_target_util.c | 5 ++---
include/linux/net.h | 3 +--
net/socket.c | 23 ++++++++++-------------
3 files changed, 13 insertions(+), 18 deletions(-)
^ permalink raw reply
* RE: [PATCH net-next 1/6] net: Make vxlan/geneve default udp ports public
From: Manish Chopra @ 2016-04-09 20:46 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev, Ariel Elior, Yuval Mintz
In-Reply-To: <CAEh+42j+y=cKUDNMQrPdHTozz5=P9pmbQOyKir6DOf=wDJvHSg@mail.gmail.com>
> -----Original Message-----
> From: Jesse Gross [mailto:jesse@kernel.org]
> Sent: Saturday, April 09, 2016 9:36 PM
> To: Manish Chopra <manish.chopra@qlogic.com>
> Cc: David Miller <davem@davemloft.net>; netdev <netdev@vger.kernel.org>;
> Ariel Elior <Ariel.Elior@qlogic.com>; Yuval Mintz <Yuval.Mintz@qlogic.com>
> Subject: Re: [PATCH net-next 1/6] net: Make vxlan/geneve default udp ports
> public
>
> On Sat, Apr 9, 2016 at 10:17 AM, Manish Chopra <manish.chopra@qlogic.com>
> wrote:
> > Rationale behind this change is that with some OVS configuration
> > UDP ports doesn't get notified to the driver using
> > .ndo_[add|del]_vxlan_port. So for the driver to work with
> > these specific ports in that environment we need to have them configured
> > on adapter by default for the required hardware offload support.
>
> I think you are referring to old out of tree code - no version of
> upstream OVS does this. In addition, any old code won't work against
> the new kernels that would include this driver update anyways so there
> won't be a benefit in any case.
>
> Please just use the normal registration mechanism that is already
> exposed. I also noticed that in the Geneve case you aren't currently
> registering for port notifications and just using the assigned port
> number in all cases, which isn't right.
In the past I have tried openvswitch release package [V2.4.0] from openvswitch.org
http://openvswitch.org/releases/
I have tried configuring ovs there on some redhat 7.x kernel with above mentioned package utility "ovs-vsctl" where ports were not notified to drivers.
Till earlier versions of openvswitch package [V2.3.2] - It was fine and UDP ports were used to be notified to the driver
I thought that the same [No port config notification to the drivers] problem would be with latest upstream OVS, isn't it ? which is why configuration of at least default ports is done by default in drivers.
For upstream OVS, is there any other openvswitch package used ? Can't the above release package be used over net-next/upstream kernel ?
If latest OVS notifies to configure UDP ports to the driver - I would simply skip default ports configuration by default and instead use .ndo_[add|del]_xxxx for both vxlan and geneve.
Thanks,
Manish
^ permalink raw reply
* Re: [PATCH net-next] ipv6: fix inet6_lookup_listener()
From: David Miller @ 2016-04-09 20:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, maze
In-Reply-To: <1460214073.6473.491.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 09 Apr 2016 08:01:13 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> A stupid refactoring bug in inet6_lookup_listener() needs to be fixed
> in order to get proper SO_REUSEPORT behavior.
>
> Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Maciej Żenczykowski <maze@google.com>
Applied, thanks Eric.
^ permalink raw reply
* 我的相册在
From: 我的相册在 @ 2016-04-09 20:53 UTC (permalink / raw)
To: netdev
你的老朋友邀你来Q群:343257759 抢红包 抢秒杀 抢vip 什么都要抢。太刺激了。不靠手气只拼手速
^ permalink raw reply
* LOAN
From: darlehen @ 2016-04-08 22:03 UTC (permalink / raw)
To: Recipients
Brauchen Sie einen Kredit? Wir bieten Darlehen in 2% gelten heute Kontakt mit uns auf: legacyassetgrougp@hotmail.com
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: Make vxlan/geneve default udp ports public
From: Jesse Gross @ 2016-04-09 21:48 UTC (permalink / raw)
To: Manish Chopra; +Cc: David Miller, netdev, Ariel Elior, Yuval Mintz
In-Reply-To: <BLUPR11MB011432C1D124F762CC278E9E93920@BLUPR11MB0114.namprd11.prod.outlook.com>
On Sat, Apr 9, 2016 at 5:46 PM, Manish Chopra <manish.chopra@qlogic.com> wrote:
>> -----Original Message-----
>> From: Jesse Gross [mailto:jesse@kernel.org]
>> Sent: Saturday, April 09, 2016 9:36 PM
>> To: Manish Chopra <manish.chopra@qlogic.com>
>> Cc: David Miller <davem@davemloft.net>; netdev <netdev@vger.kernel.org>;
>> Ariel Elior <Ariel.Elior@qlogic.com>; Yuval Mintz <Yuval.Mintz@qlogic.com>
>> Subject: Re: [PATCH net-next 1/6] net: Make vxlan/geneve default udp ports
>> public
>>
>> On Sat, Apr 9, 2016 at 10:17 AM, Manish Chopra <manish.chopra@qlogic.com>
>> wrote:
>> > Rationale behind this change is that with some OVS configuration
>> > UDP ports doesn't get notified to the driver using
>> > .ndo_[add|del]_vxlan_port. So for the driver to work with
>> > these specific ports in that environment we need to have them configured
>> > on adapter by default for the required hardware offload support.
>>
>> I think you are referring to old out of tree code - no version of
>> upstream OVS does this. In addition, any old code won't work against
>> the new kernels that would include this driver update anyways so there
>> won't be a benefit in any case.
>>
>> Please just use the normal registration mechanism that is already
>> exposed. I also noticed that in the Geneve case you aren't currently
>> registering for port notifications and just using the assigned port
>> number in all cases, which isn't right.
>
> In the past I have tried openvswitch release package [V2.4.0] from openvswitch.org
> http://openvswitch.org/releases/
>
> I have tried configuring ovs there on some redhat 7.x kernel with above mentioned package utility "ovs-vsctl" where ports were not notified to drivers.
> Till earlier versions of openvswitch package [V2.3.2] - It was fine and UDP ports were used to be notified to the driver
>
> I thought that the same [No port config notification to the drivers] problem would be with latest upstream OVS, isn't it ? which is why configuration of at least default ports is done by default in drivers.
> For upstream OVS, is there any other openvswitch package used ? Can't the above release package be used over net-next/upstream kernel ?
There was a bug in code that was backported for use with older kernels
that prevented notifications from happening to the drivers. This is
fixed in the most recent version. In addition, this was never present
in the original code that is part of the upstream kernel. All versions
of userspace are compatible with all kernel modules, regardless of how
they were released.
> If latest OVS notifies to configure UDP ports to the driver - I would simply skip default ports configuration by default and instead use .ndo_[add|del]_xxxx for both vxlan and geneve.
That would be great, thanks.
^ permalink raw reply
* [PATCH] sh_eth: re-enable-E-MAC interrupts in sh_eth_set_ringparam()
From: Sergei Shtylyov @ 2016-04-09 23:28 UTC (permalink / raw)
To: netdev, linux-renesas-soc
The E-MAC interrupts are left disabled when the ring parameters are changed
via 'ethtool'. In order to fix this, it's enough to call sh_eth_dev_init()
with 'true' instead of 'false' for the second argument (which conveniently
allows us to remove the following code re-enabling E-DMAC interrupts and
reception).
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net.git' repo.
drivers/net/ethernet/renesas/sh_eth.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
Index: net/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -2194,17 +2194,13 @@ static int sh_eth_set_ringparam(struct n
__func__);
return ret;
}
- ret = sh_eth_dev_init(ndev, false);
+ ret = sh_eth_dev_init(ndev, true);
if (ret < 0) {
netdev_err(ndev, "%s: sh_eth_dev_init failed.\n",
__func__);
return ret;
}
- mdp->irq_enabled = true;
- sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
- /* Setting the Rx mode will start the Rx process. */
- sh_eth_write(ndev, EDRRR_R, EDRRR);
netif_device_attach(ndev);
}
^ permalink raw reply
* Re: optimizations to sk_buff handling in rds_tcp_data_ready
From: Sowmini Varadhan @ 2016-04-10 0:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1460038560.6473.397.camel@edumazet-glaptop3.roam.corp.google.com>
On (04/07/16 07:16), Eric Dumazet wrote:
> Use skb split like TCP in output path ?
> Really, pskb_expand_head() is not supposed to copy payload ;)
Question- how come skb_split doesnt have to deal with frag_list
and do a skb_walk_frags()? Couldn't the split-line be somewhere
in the frag_list? Also even for the skb_split_inside_header,
dont we have to set
skb_shinfo(skb1)->frag_list = skb_shinfo(skb)->frag_list;
and cut loose the skb_shinfo(skb)->frag_list?
As I try to mimic skb_split in some new set of "skb_carve"
funtions, I'm running into all the various frag_list cases. I'm
afraid I might end up needing most of the stuff under the "Pure
masohism" (sic) comment in __pskb_pull_tail().
--Sowmini
^ permalink raw reply
* Re: [PATCH] sh_eth: re-enable-E-MAC interrupts in sh_eth_set_ringparam()
From: David Miller @ 2016-04-10 1:27 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <2542968.R3YjY2kHV4@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 10 Apr 2016 02:28:41 +0300
> The E-MAC interrupts are left disabled when the ring parameters are changed
> via 'ethtool'. In order to fix this, it's enough to call sh_eth_dev_init()
> with 'true' instead of 'false' for the second argument (which conveniently
> allows us to remove the following code re-enabling E-DMAC interrupts and
> reception).
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 net-next 1/6] sctp: add sctp_info dump api for sctp_diag
From: Xin Long @ 2016-04-10 6:42 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Vlad Yasevich,
daniel, davem
In-Reply-To: <57091CB6.1070207@mojatatu.com>
On Sat, Apr 9, 2016 at 11:16 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> Appreciate these patches. Finally some love for sctp.
> Small comment below:
>
>
> On 16-04-09 12:53 AM, Xin Long wrote:
>>
>> sctp_diag will dump some important details of sctp's assoc or ep, we use
>> sctp_info to describe them, sctp_get_sctp_info to get them, and export
>> it to sctp_diag.ko.
>>
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>> ---
>> include/linux/sctp.h | 65 +++++++++++++++++++++++++++++++++++++
>> include/net/sctp/sctp.h | 3 ++
>> net/sctp/socket.c | 86
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 154 insertions(+)
>>
>> diff --git a/include/linux/sctp.h b/include/linux/sctp.h
>> index a9414fd..a448ebc 100644
>> --- a/include/linux/sctp.h
>> +++ b/include/linux/sctp.h
>> @@ -705,4 +705,69 @@ typedef struct sctp_auth_chunk {
>> sctp_authhdr_t auth_hdr;
>> } __packed sctp_auth_chunk_t;
>>
>> +struct sctp_info {
>> + __u32 sctpi_tag;
>> + __u32 sctpi_state;
>> + __u32 sctpi_rwnd;
>> + __u16 sctpi_unackdata;
>> + __u16 sctpi_penddata;
>> + __u16 sctpi_instrms;
>> + __u16 sctpi_outstrms;
>> + __u32 sctpi_fragmentation_point;
>> + __u32 sctpi_inqueue;
>> + __u32 sctpi_outqueue;
>> + __u32 sctpi_overall_error;
>> + __u32 sctpi_max_burst;
>> + __u32 sctpi_maxseg;
>> + __u32 sctpi_peer_rwnd;
>> + __u32 sctpi_peer_tag;
>> + __u8 sctpi_peer_capable;
>> + __u8 sctpi_peer_sack;
>> +
>> + /* assoc status info */
>> + __u64 sctpi_isacks;
>> + __u64 sctpi_osacks;
>> + __u64 sctpi_opackets;
>> + __u64 sctpi_ipackets;
>> + __u64 sctpi_rtxchunks;
>> + __u64 sctpi_outofseqtsns;
>> + __u64 sctpi_idupchunks;
>> + __u64 sctpi_gapcnt;
>> + __u64 sctpi_ouodchunks;
>> + __u64 sctpi_iuodchunks;
>> + __u64 sctpi_oodchunks;
>> + __u64 sctpi_iodchunks;
>> + __u64 sctpi_octrlchunks;
>> + __u64 sctpi_ictrlchunks;
>> +
>> + /* primary transport info */
>> + struct sockaddr_storage sctpi_p_address;
>> + __s32 sctpi_p_state;
>> + __u32 sctpi_p_cwnd;
>> + __u32 sctpi_p_srtt;
>> + __u32 sctpi_p_rto;
>> + __u32 sctpi_p_hbinterval;
>> + __u32 sctpi_p_pathmaxrxt;
>> + __u32 sctpi_p_sackdelay;
>> + __u32 sctpi_p_sackfreq;
>> + __u32 sctpi_p_ssthresh;
>> + __u32 sctpi_p_partial_bytes_acked;
>> + __u32 sctpi_p_flight_size;
>> + __u16 sctpi_p_error;
>> +
>> + /* sctp sock info */
>> + __u32 sctpi_s_autoclose;
>> + __u32 sctpi_s_adaptation_ind;
>> + __u32 sctpi_s_pd_point;
>> + __u8 sctpi_s_nodelay;
>> + __u8 sctpi_s_disable_fragments;
>> + __u8 sctpi_s_v4mapped;
>> + __u8 sctpi_s_frag_interleave;
>> +};
>> +
>
>
>
> Can you double check to make sure this is 32 bit aligned
> (no holes) maybe in your case 64 bit aligned?
> Sticking + __u16 sctpi_p_error in there seems
> to kill it.
yes, I will check this structure all.
>
> Also, any plans to do the netlink events and destroy features?
yeah, maybe after this one, we will do it.
but for destroy feature, do you have any idea to test, cause
ss of iproute seems cannot cover it, even .dump_one, neither.
do we have to write code to test them?
netlink events? sorry, what's that for? I didn't see it in tcp_diag.
>
> cheers,
> jamal
^ permalink raw reply
* [PATCHv2] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-04-10 7:37 UTC (permalink / raw)
To: Kalle Valo, Eyal Reizer,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1460273570-12298-1-git-send-email-eyalr-l0cyMroinI0@public.gmane.org>
Add support for using with both wl12xx and wl18xx.
- all wilink family needs special init command for entering wspi mode.
extra clock cycles should be sent after the spi init command while the
cs pin is high.
- switch to controling the cs pin from the spi driver for achieveing the
above.
- the selected cs gpio is read from the spi device-tree node using the
cs-gpios field and setup as a gpio.
- See the example below for specifying the cs gpio using the cs-gpios entry
&spi0 {
...
cs-gpios = <&gpio0 5 0>;
...
wlcore: wlcore@0 {
compatible = "ti,wl1835";
...
...
};
};
Signed-off-by: Eyal Reizer <eyalr-l0cyMroinI0@public.gmane.org>
---
v1 -> v2: update device tree bindings documentation
.../bindings/net/wireless/ti,wlcore,spi.txt | 50 +++++-
drivers/net/wireless/ti/wlcore/spi.c | 176 +++++++++++++++++---
2 files changed, 200 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..912ab0c 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,31 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
document describes the binding for the SPI connected chip.
Required properties:
-- compatible : Should be "ti,wl1271"
+- compatible : Should be one of the following:
+ * "ti,wl1271"
+ * "ti,wl1273"
+ * "ti,wl1281"
+ * "ti,wl1283"
+ * "ti,wl1801"
+ * "ti,wl1805"
+ * "ti,wl1807"
+ * "ti,wl1831"
+ * "ti,wl1835"
+ * "ti,wl1837"
- reg : Chip select address of device
- spi-max-frequency : Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
- interrupt-parent, interrupts :
Should contain parameters for 1 interrupt line.
Interrupt parameters: parent, line number, type.
-- vwlan-supply : Point the node of the regulator that powers/enable the wl1271 chip
+- vwlan-supply : Point the node of the regulator that powers/enable the
+ wl12xx/wl18xx chip
+- cs-gpios : GPIO pin used as the spi chip select
Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
- clock-xtal : boolean, clock is generated from XTAL
- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,10 +33,16 @@ Optional properties:
Examples:
+For wl12xx family:
&spi1 {
- wl1271@1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ cs-gpios = <&gpio0 5 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ wlcore: wlcore@0 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <48000000>;
clock-xtal;
@@ -34,3 +52,21 @@ Examples:
vwlan-supply = <&vwlan_fixed>;
};
};
+
+For wl18xx family:
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ cs-gpios = <&gpio0 5 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ wlcore: wlcore@0 {
+ compatible = "ti,wl1835";
+ vwlan-supply = <&wlan_en_reg>;
+ spi-max-frequency = <48000000>;
+ reg = <0>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ };
+};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index 020ac1a..fb48a0d 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -32,6 +32,7 @@
#include <linux/platform_device.h>
#include <linux/of_irq.h>
#include <linux/regulator/consumer.h>
+#include <linux/gpio.h>
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -70,16 +71,30 @@
#define WSPI_MAX_CHUNK_SIZE 4092
/*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
*/
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
/* Maximum number of SPI write chunks */
#define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
+struct wilink_familiy_data {
+ char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+ .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+ .name = "wl12xx",
+};
+
struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -120,6 +135,8 @@ static void wl12xx_spi_init(struct device *child)
struct spi_transfer t;
struct spi_message m;
u8 *cmd = kzalloc(WSPI_INIT_CMD_LEN, GFP_KERNEL);
+ struct spi_device *spi = (struct spi_device *)glue->dev;
+ struct spi_master *master = spi->master;
if (!cmd) {
dev_err(child->parent,
@@ -127,6 +144,15 @@ static void wl12xx_spi_init(struct device *child)
return;
}
+ if (!master->cs_gpios) {
+ dev_err(child->parent,
+ "spi chip select pin missing in platform data!\n");
+ return;
+ }
+
+ /* Drive CS line low */
+ gpio_direction_output(master->cs_gpios[0], 0);
+
memset(&t, 0, sizeof(t));
spi_message_init(&m);
@@ -163,6 +189,26 @@ static void wl12xx_spi_init(struct device *child)
spi_message_add_tail(&t, &m);
spi_sync(to_spi_device(glue->dev), &m);
+
+ /* Send extra clocks with CS high. this is required by the wilink
+ * family in order for successfully enter WSPI mode
+ */
+ gpio_direction_output(master->cs_gpios[0], 1);
+
+ memset(&m, 0, sizeof(m));
+ spi_message_init(&m);
+
+ cmd[0] = 0xff;
+ cmd[1] = 0xff;
+ cmd[2] = 0xff;
+ cmd[3] = 0xff;
+ swab32s((u32 *)cmd);
+
+ t.tx_buf = cmd;
+ t.len = 4;
+ spi_message_add_tail(&t, &m);
+ spi_sync(to_spi_device(glue->dev), &m);
+
kfree(cmd);
}
@@ -213,6 +259,16 @@ static int __must_check wl12xx_spi_raw_read(struct device *child, int addr,
u32 *busy_buf;
u32 *cmd;
u32 chunk_len;
+ struct spi_device *spi = (struct spi_device *)glue->dev;
+ struct spi_master *master = spi->master;
+
+ if (!master->cs_gpios) {
+ dev_err(child->parent,
+ "spi chip select pin missing in platform data!\n");
+ return -EINVAL;
+ }
+ /* Drive CS line low */
+ gpio_direction_output(master->cs_gpios[0], 0);
while (len > 0) {
chunk_len = min_t(size_t, WSPI_MAX_CHUNK_SIZE, len);
@@ -267,25 +323,44 @@ static int __must_check wl12xx_spi_raw_read(struct device *child, int addr,
len -= chunk_len;
}
+ /* Drive CS line high */
+ gpio_direction_output(master->cs_gpios[0], 1);
return 0;
}
-static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
- void *buf, size_t len, bool fixed)
+static int __wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed)
{
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
- /* SPI write buffers - 2 for each chunk */
- struct spi_transfer t[2 * WSPI_MAX_NUM_OF_CHUNKS];
+ struct spi_transfer *t;
struct spi_message m;
u32 commands[WSPI_MAX_NUM_OF_CHUNKS]; /* 1 command per chunk */
u32 *cmd;
u32 chunk_len;
int i;
+ struct spi_device *spi = (struct spi_device *)glue->dev;
+ struct spi_master *master = spi->master;
+
+ if (!master->cs_gpios) {
+ dev_err(child->parent,
+ "spi chip select pin missing in platform data!\n");
+ return -EINVAL;
+ }
+
+ /* SPI write buffers - 2 for each chunk */
+ t = kzalloc(sizeof(*t) * 2 * WSPI_MAX_NUM_OF_CHUNKS, GFP_KERNEL);
+ if (!t) {
+ dev_err(child->parent,
+ "could not allocate spi write buffer\n");
+ return -ENOMEM;
+ }
+
+ /* Drive CS line low */
+ gpio_direction_output(master->cs_gpios[0], 0);
WARN_ON(len > SPI_AGGR_BUFFER_SIZE);
spi_message_init(&m);
- memset(t, 0, sizeof(t));
cmd = &commands[0];
i = 0;
@@ -318,9 +393,29 @@ static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
spi_sync(to_spi_device(glue->dev), &m);
+ /* Drive CS line high */
+ gpio_direction_output(master->cs_gpios[0], 1);
+
+ kfree(t);
return 0;
}
+static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed)
+{
+ int ret;
+
+ /* The ELP wakeup write may fail the first time due to internal
+ * hardware latency. It is safer to send the wakeup command twice to
+ * avoid unexpected failures.
+ */
+ if (addr == HW_ACCESS_ELP_CTRL_REG)
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+
+ return ret;
+}
+
/**
* wl12xx_spi_set_power - power on/off the wl12xx unit
* @child: wl12xx device handle.
@@ -349,17 +444,38 @@ static int wl12xx_spi_set_power(struct device *child, bool enable)
return ret;
}
+/**
+ * wl12xx_spi_set_block_size
+ *
+ * This function is not needed for spi mode, but need to be present.
+ * Without it defined the wlcore fallback to use the wrong packet
+ * allignment on tx.
+ */
+static void wl12xx_spi_set_block_size(struct device *child,
+ unsigned int blksz)
+{
+}
+
static struct wl1271_if_operations spi_ops = {
.read = wl12xx_spi_raw_read,
.write = wl12xx_spi_raw_write,
.reset = wl12xx_spi_reset,
.init = wl12xx_spi_init,
.power = wl12xx_spi_set_power,
- .set_block_size = NULL,
+ .set_block_size = wl12xx_spi_set_block_size,
};
static const struct of_device_id wlcore_spi_of_match_table[] = {
- { .compatible = "ti,wl1271" },
+ { .compatible = "ti,wl1271", .data = &wl12xx_data},
+ { .compatible = "ti,wl1273", .data = &wl12xx_data},
+ { .compatible = "ti,wl1281", .data = &wl12xx_data},
+ { .compatible = "ti,wl1283", .data = &wl12xx_data},
+ { .compatible = "ti,wl1801", .data = &wl18xx_data},
+ { .compatible = "ti,wl1805", .data = &wl18xx_data},
+ { .compatible = "ti,wl1807", .data = &wl18xx_data},
+ { .compatible = "ti,wl1831", .data = &wl18xx_data},
+ { .compatible = "ti,wl1835", .data = &wl18xx_data},
+ { .compatible = "ti,wl1837", .data = &wl18xx_data},
{ }
};
MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table);
@@ -375,18 +491,24 @@ static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue *glue,
struct wlcore_platdev_data *pdev_data)
{
struct device_node *dt_node = spi->dev.of_node;
- int ret;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_node(wlcore_spi_of_match_table, dt_node);
+ if (!of_id)
+ return -ENODEV;
+
+ wilink_data = of_id->data;
+ dev_info(&spi->dev, "selected chip familiy is %s\n",
+ wilink_data->name);
if (of_find_property(dt_node, "clock-xtal", NULL))
pdev_data->ref_clock_xtal = true;
- ret = of_property_read_u32(dt_node, "ref-clock-frequency",
- &pdev_data->ref_clock_freq);
- if (IS_ERR_VALUE(ret)) {
- dev_err(glue->dev,
- "can't get reference clock frequency (%d)\n", ret);
- return ret;
- }
+ /* optional clock frequency params */
+ of_property_read_u32(dt_node, "ref-clock-frequency",
+ &pdev_data->ref_clock_freq);
+ of_property_read_u32(dt_node, "tcxo-clock-frequency",
+ &pdev_data->tcxo_clock_freq);
return 0;
}
@@ -397,6 +519,7 @@ static int wl1271_probe(struct spi_device *spi)
struct wlcore_platdev_data pdev_data;
struct resource res[1];
int ret;
+ struct spi_master *master = spi->master;
memset(&pdev_data, 0x00, sizeof(pdev_data));
@@ -410,6 +533,12 @@ static int wl1271_probe(struct spi_device *spi)
glue->dev = &spi->dev;
+ if (!master->cs_gpios) {
+ dev_err(glue->dev,
+ "spi chip select pin missing in platform data!\n");
+ return -EINVAL;
+ }
+
spi_set_drvdata(spi, glue);
/* This is the only SPI value that we need to set here, the rest
@@ -431,15 +560,21 @@ static int wl1271_probe(struct spi_device *spi)
return ret;
}
+ if (gpio_request(master->cs_gpios[0], "spi1-cs0"))
+ return -EINVAL;
+
ret = spi_setup(spi);
if (ret < 0) {
dev_err(glue->dev, "spi_setup failed\n");
+ gpio_free(master->cs_gpios[0]);
return ret;
}
- glue->core = platform_device_alloc("wl12xx", PLATFORM_DEVID_AUTO);
+ glue->core = platform_device_alloc(wilink_data->name,
+ PLATFORM_DEVID_AUTO);
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device\n");
+ gpio_free(master->cs_gpios[0]);
return -ENOMEM;
}
@@ -474,14 +609,17 @@ static int wl1271_probe(struct spi_device *spi)
out_dev_put:
platform_device_put(glue->core);
+ gpio_free(master->cs_gpios[0]);
return ret;
}
static int wl1271_remove(struct spi_device *spi)
{
struct wl12xx_spi_glue *glue = spi_get_drvdata(spi);
+ struct spi_master *master = spi->master;
platform_device_unregister(glue->core);
+ gpio_free(master->cs_gpios[0]);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: [RFC PATCH v2 1/5] bpf: add PHYS_DEV prog type for early driver filter
From: Thomas Graf @ 2016-04-10 7:55 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jamal Hadi Salim, Tom Herbert, Jesper Dangaard Brouer,
Brenden Blanco, David S. Miller, Linux Kernel Network Developers,
Or Gerlitz, Daniel Borkmann, Eric Dumazet, Edward Cree,
john fastabend, Johannes Berg, eranlinuxmellanox, Lorenzo Colitti,
linux-mm
In-Reply-To: <20160409172634.GA55330@ast-mbp.thefacebook.com>
On 04/09/16 at 10:26am, Alexei Starovoitov wrote:
> On Sat, Apr 09, 2016 at 11:29:18AM -0400, Jamal Hadi Salim wrote:
> > If this is _forwarding only_ it maybe useful to look at
> > Alexey's old code in particular the DMA bits;
> > he built his own lookup algorithm but sounds like bpf is
> > a much better fit today.
>
> a link to these old bits?
>
> Just to be clear: this rfc is not the only thing we're considering.
> In particular huawei guys did a monster effort to improve performance
> in this area as well. We'll try to blend all the code together and
> pick what's the best.
What's the plan on opening the discussion on this? Can we get a peek?
Is it an alternative to XDP and the driver hook? Different architecture
or just different implementation? I understood it as another pseudo
skb model with a path on converting to real skbs for stack processing.
I really like the current proposal by Brenden for its simplicity and
targeted compatibility with cls_bpf.
--
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
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