* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Alexei Starovoitov @ 2016-04-11 22:21 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Sagi Grimberg, Bart Van Assche, Christoph Hellwig,
James Bottomley, Tom Herbert, Brenden Blanco,
lsf@lists.linux-foundation.org, linux-mm, netdev@vger.kernel.org,
lsf-pc@lists.linux-foundation.org
In-Reply-To: <20160411234157.3fc9c6fe@redhat.com>
On Mon, Apr 11, 2016 at 11:41:57PM +0200, Jesper Dangaard Brouer wrote:
>
> On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg <sagi@grimberg.me> wrote:
>
> > >> This is also very interesting for storage targets, which face the same
> > >> issue. SCST has a mode where it caches some fully constructed SGLs,
> > >> which is probably very similar to what NICs want to do.
> > >
> > > I think a cached allocator for page sets + the scatterlists that
> > > describe these page sets would not only be useful for SCSI target
> > > implementations but also for the Linux SCSI initiator. Today the scsi-mq
> > > code reserves space in each scsi_cmnd for a scatterlist of
> > > SCSI_MAX_SG_SEGMENTS. If scatterlists would be cached together with page
> > > sets less memory would be needed per scsi_cmnd.
> >
> > If we go down this road how about also attaching some driver opaques
> > to the page sets?
>
> That was the ultimate plan... to leave some opaques bytes left in the
> page struct that drivers could use.
>
> In struct page I would need a pointer back to my page_pool struct and a
> page flag. Then, I would need room to store the dma_unmap address.
> (And then some of the usual fields are still needed, like the refcnt,
> and reusing some of the list constructs). And a zero-copy cross-domain
> id.
I don't think we need to add anything to struct page.
This is supposed to be small cache of dma_mapped pages with lockless access.
It can be implemented as an array or link list where every element
is dma_addr and pointer to page. If it is full, dma_unmap_page+put_page to
send it to back to page allocator.
--
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 iproute2 0/4] vxlan: add VXLAN-GPE support
From: Stephen Hemminger @ 2016-04-11 22:17 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev
In-Reply-To: <cover.1460032274.git.jbenc@redhat.com>
On Thu, 7 Apr 2016 14:36:25 +0200
Jiri Benc <jbenc@redhat.com> wrote:
> This patchset adds a couple of refinements to the 'external' keyword and
> adds support for configuring VXLAN-GPE interfaces.
>
> The VXLAN-GPE support was recently merged to net-next.
>
> The first patch is not intended to be applied directly but I still include
> it in order for this patchset to be compilable and testable by those
> interested.
>
> Jiri Benc (4):
> if_link.h: rebase to the kernel
> vxlan: 'external' implies 'nolearning'
> ip-link.8: document "external" flag for vxlan
> vxlan: add support for VXLAN-GPE
>
> include/linux/if_link.h | 1 +
> ip/iplink_vxlan.c | 14 ++++++++++++--
> man/man8/ip-link.8.in | 17 +++++++++++++++++
> 3 files changed, 30 insertions(+), 2 deletions(-)
>
Applied to net-next
^ permalink raw reply
* Re: [PATCH] iproute2: tc_bpf.c: fix building with musl libc
From: Stephen Hemminger @ 2016-04-11 22:17 UTC (permalink / raw)
To: Gustavo Zacarias; +Cc: netdev
In-Reply-To: <1460120373-32096-1-git-send-email-gustavo@zacarias.com.ar>
On Fri, 8 Apr 2016 09:59:33 -0300
Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
> We need limits.h for PATH_MAX, fixes:
>
> tc_bpf.c: In function ‘bpf_map_selfcheck_pinned’:
> tc_bpf.c:222:12: error: ‘PATH_MAX’ undeclared (first use in this
> function)
> char file[PATH_MAX], buff[4096];
>
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Applied
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Alexander Duyck @ 2016-04-11 22:02 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Sagi Grimberg, Bart Van Assche, Christoph Hellwig,
James Bottomley, Tom Herbert, Brenden Blanco,
lsf@lists.linux-foundation.org, linux-mm, netdev@vger.kernel.org,
lsf-pc@lists.linux-foundation.org, Alexei Starovoitov
In-Reply-To: <20160411234157.3fc9c6fe@redhat.com>
On Mon, Apr 11, 2016 at 2:41 PM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
>
> On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg <sagi@grimberg.me> wrote:
>
>> >> This is also very interesting for storage targets, which face the same
>> >> issue. SCST has a mode where it caches some fully constructed SGLs,
>> >> which is probably very similar to what NICs want to do.
>> >
>> > I think a cached allocator for page sets + the scatterlists that
>> > describe these page sets would not only be useful for SCSI target
>> > implementations but also for the Linux SCSI initiator. Today the scsi-mq
>> > code reserves space in each scsi_cmnd for a scatterlist of
>> > SCSI_MAX_SG_SEGMENTS. If scatterlists would be cached together with page
>> > sets less memory would be needed per scsi_cmnd.
>>
>> If we go down this road how about also attaching some driver opaques
>> to the page sets?
>
> That was the ultimate plan... to leave some opaques bytes left in the
> page struct that drivers could use.
>
> In struct page I would need a pointer back to my page_pool struct and a
> page flag. Then, I would need room to store the dma_unmap address.
> (And then some of the usual fields are still needed, like the refcnt,
> and reusing some of the list constructs). And a zero-copy cross-domain
> id.
>
>
> For my packet-page idea, I would need a packet length and an offset
> where data starts (I can derive the "head-room" for encap from these
> two).
Have you taken a look at possibly trying to optimize the DMA pool API
to work with pages? It sounds like it is supposed to do something
similar to what you are wanting to do.
- Alex
^ permalink raw reply
* Re: [PATCH 0/9] RxRPC: 2nd rewrite part 1
From: David Howells @ 2016-04-11 22:01 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, linux-afs, netdev, linux-kernel
In-Reply-To: <20160411.153511.1531573815825221764.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> Series applied, but I had to fix up some trailing whitespace (reported by
> GIT) by hand.
Do you perchance have a git hook script for checking for trailing whitespace?
David
^ permalink raw reply
* Re: [PATCH iproute2 -master 0/3] Minor tc/bpf updates
From: Stephen Hemminger @ 2016-04-11 21:55 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, alexei.starovoitov
In-Reply-To: <cover.1460153854.git.daniel@iogearbox.net>
On Sat, 9 Apr 2016 00:32:02 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Some minor updates to improve error reporting, add signatures
> and recently introduced map flags attribute. Set is against
> master branch.
>
> Thanks!
>
> Daniel Borkmann (3):
> tc, bpf: add new csum and tunnel signatures
> tc, bpf: further improve error reporting
> tc, bpf: add support for map pre/allocation
>
> examples/bpf/bpf_cyclic.c | 9 ++++-
> examples/bpf/bpf_graft.c | 8 +++-
> examples/bpf/bpf_prog.c | 2 +
> examples/bpf/bpf_shared.c | 8 +++-
> examples/bpf/bpf_tailcall.c | 29 ++++++++++++--
> include/bpf_api.h | 52 ++++--------------------
> include/bpf_elf.h | 1 +
> tc/tc_bpf.c | 98 +++++++++++++++++++++++++++++++++++----------
> tc/tc_bpf.h | 4 ++
> 9 files changed, 138 insertions(+), 73 deletions(-)
>
Applied thanks
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-11 21:41 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Bart Van Assche, Christoph Hellwig, James Bottomley, Tom Herbert,
Brenden Blanco, lsf@lists.linux-foundation.org, linux-mm,
netdev@vger.kernel.org, lsf-pc@lists.linux-foundation.org,
Alexei Starovoitov, brouer
In-Reply-To: <570A9F5B.5010600@grimberg.me>
On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg <sagi@grimberg.me> wrote:
> >> This is also very interesting for storage targets, which face the same
> >> issue. SCST has a mode where it caches some fully constructed SGLs,
> >> which is probably very similar to what NICs want to do.
> >
> > I think a cached allocator for page sets + the scatterlists that
> > describe these page sets would not only be useful for SCSI target
> > implementations but also for the Linux SCSI initiator. Today the scsi-mq
> > code reserves space in each scsi_cmnd for a scatterlist of
> > SCSI_MAX_SG_SEGMENTS. If scatterlists would be cached together with page
> > sets less memory would be needed per scsi_cmnd.
>
> If we go down this road how about also attaching some driver opaques
> to the page sets?
That was the ultimate plan... to leave some opaques bytes left in the
page struct that drivers could use.
In struct page I would need a pointer back to my page_pool struct and a
page flag. Then, I would need room to store the dma_unmap address.
(And then some of the usual fields are still needed, like the refcnt,
and reusing some of the list constructs). And a zero-copy cross-domain
id.
For my packet-page idea, I would need a packet length and an offset
where data starts (I can derive the "head-room" for encap from these
two).
--
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
--
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 for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Or Gerlitz @ 2016-04-11 21:37 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, Matan Barak, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Leon Romanovsky, Tal Alon
In-Reply-To: <CALzJLG-PxUz9ov+cv4uiNSGpuxy0s9KamTvamV_g72SctqdhFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 12, 2016 at 12:24 AM, Saeed Mahameed
<saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
> On Tue, Apr 12, 2016 at 12:17 AM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> feature --> features
> Correct, will fix.
>>> * Add vport to steering commands for SRIOV ACL support
>>> * Add mlcr, pcmr and mcia registers for dump module EEPROM
>>> * Add support for FCS, baeacon led and disable_link bits to hca caps
>>> * Add CQE period mode bit in CQ context for CQE based CQ
>>> moderation support
>>> * Add umr SQ bit for fragmented memory registration
>>> * Add needed bits and caps for Striding RQ support
>> AFAIK, all the above are features will go through net-next, what made
>> you anticipate conflicts with linux-rdma?
> FCS bit is needed also for rdma, so we took the liberty of updating
> all the needed HW structs, bits, caps, etc ..
> at once for all mlx5 features planned for 4.7 regardless of rdma/net conflicts.
The cover letter states that this series deals with shared code.
I guess you might also could extend it a bit to deal also with code
that you suspect could lead to conflicts, but I don't see why it
evolved to that extent.
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Lsf] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Eric Dumazet @ 2016-04-11 21:27 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: lsf, Tom Herbert, Brenden Blanco, James Bottomley, linux-mm,
netdev@vger.kernel.org, lsf-pc, Alexei Starovoitov
In-Reply-To: <20160411222309.499a2125@redhat.com>
On Mon, 2016-04-11 at 22:23 +0200, Jesper Dangaard Brouer wrote:
> If we have a page-pool recycle facility, then we could use the trick,
> right? (As we know that get_page_unless_zero() cannot happen for pages
> in the pool).
Well, if you disable everything that possibly use
get_page_unless_zero(), I guess this could work.
But then, you'll have to spy lkml traffic forever to make sure no new
feature is added in the kernel, using this get_page_unless_zero() in a
new clever way.
You could use a page flag so that z BUG() triggers if
get_page_unless_zero() is attempted on one of your precious pages ;)\
We had very subtle issues before my fixes (check
35b7a1915aa33da812074744647db0d9262a555c and children), so I would not
waste time on the lock prefix avoidance at this point.
^ permalink raw reply
* Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Saeed Mahameed @ 2016-04-11 21:24 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Matan Barak, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Leon Romanovsky, Tal Alon
In-Reply-To: <CAJ3xEMghu7ZB0YM8j_YJihpuNnDzOY2LU9-cTHwoWiBeYY7VPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 12, 2016 at 12:17 AM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> feature --> features
Correct, will fix.
>
>> * Add vport to steering commands for SRIOV ACL support
>> * Add mlcr, pcmr and mcia registers for dump module EEPROM
>> * Add support for FCS, baeacon led and disable_link bits to
>> hca caps
>> * Add CQE period mode bit in CQ context for CQE based CQ
>> moderation support
>> * Add umr SQ bit for fragmented memory registration
>> * Add needed bits and caps for Striding RQ support
>
> AFAIK, all the above are features will go through net-next, what made
> you anticipate conflicts with linux-rdma?
FCS bit is needed also for rdma, so we took the liberty of updating
all the needed HW structs, bits, caps, etc ..
at once for all mlx5 features planned for 4.7 regardless of rdma/net conflicts.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Getting at the UDP headers from ->data_ready()
From: David Howells @ 2016-04-11 21:23 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: dhowells, Willem de Bruijn, Network Development
In-Reply-To: <CAF=yD-JfW6kfoQ4geO3bCCrBVng-AL=BqBuVyF2nU0tO4jpsDg@mail.gmail.com>
Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> The network and transport header pointers are still valid. Commit e6afc8ace6dd
> only changes where skb->data points to. It does not discard the data between
> skb->head and skb->data. This rxrpc follow-up patch fixes some offset
> arithmetic to the payload, which is computed relative to skb->data.
>
> There are other uses of ip_hdr and udp_hdr in udp_recvmsg and similar
> recvmsg handlers for other protocols. For instance, in the source address
> processing for recvfrom ("if (sin) { .. }")
Excellent, thanks!
David
^ permalink raw reply
* Re: [PATCHv2 net-next 4/6] sctp: add the sctp_diag.c file
From: Marcelo Ricardo Leitner @ 2016-04-11 21:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Xin Long, network dev, linux-sctp, Vlad Yasevich, daniel, davem
In-Reply-To: <1460181116.6473.483.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Apr 08, 2016 at 10:51:56PM -0700, Eric Dumazet wrote:
> On Sat, 2016-04-09 at 12:53 +0800, Xin Long wrote:
> > This one will implement all the interface of inet_diag, inet_diag_handler.
> > which includes sctp_diag_dump, sctp_diag_dump_one and sctp_diag_get_info.
>
>
> > +static int inet_assoc_diag_fill(struct sock *sk,
> > + struct sctp_association *asoc,
> > + struct sk_buff *skb,
> > + const struct inet_diag_req_v2 *req,
> > + struct user_namespace *user_ns,
> > + int portid, u32 seq, u16 nlmsg_flags,
> > + const struct nlmsghdr *unlh)
> > +{
> > + const struct inet_sock *inet = inet_sk(sk);
> > + const struct inet_diag_handler *handler;
> > + int ext = req->idiag_ext;
> > + struct inet_diag_msg *r;
> > + struct nlmsghdr *nlh;
> > + struct nlattr *attr;
> > + void *info = NULL;
> > + union sctp_addr laddr, paddr;
> > + struct dst_entry *dst;
> > + struct sctp_infox infox;
> > +
> > + handler = inet_diag_get_handler(req->sdiag_protocol);
> > + BUG_ON(!handler);
> > +
> > + nlh = nlmsg_put(skb, portid, seq, unlh->nlmsg_type, sizeof(*r),
> > + nlmsg_flags);
> > + if (!nlh)
> > + return -EMSGSIZE;
> > +
> > + r = nlmsg_data(nlh);
> > + BUG_ON(!sk_fullsock(sk));
> > +
> > + laddr = list_entry(asoc->base.bind_addr.address_list.next,
> > + struct sctp_sockaddr_entry, list)->a;
> > + paddr = asoc->peer.primary_path->ipaddr;
> > + dst = asoc->peer.primary_path->dst;
> > +
> > + r->idiag_family = sk->sk_family;
> > + r->id.idiag_sport = htons(asoc->base.bind_addr.port);
> > + r->id.idiag_dport = htons(asoc->peer.port);
> > + r->id.idiag_if = dst ? dst->dev->ifindex : 0;
> > + sock_diag_save_cookie(sk, r->id.idiag_cookie);
> > +
> > +#if IS_ENABLED(CONFIG_IPV6)
> > + if (sk->sk_family == AF_INET6) {
> > + *(struct in6_addr *)r->id.idiag_src = laddr.v6.sin6_addr;
> > + *(struct in6_addr *)r->id.idiag_dst = paddr.v6.sin6_addr;
> > + } else
> > +#endif
> > + {
> > + memset(&r->id.idiag_src, 0, sizeof(r->id.idiag_src));
> > + memset(&r->id.idiag_dst, 0, sizeof(r->id.idiag_dst));
> > +
> > + r->id.idiag_src[0] = laddr.v4.sin_addr.s_addr;
> > + r->id.idiag_dst[0] = paddr.v4.sin_addr.s_addr;
> > + }
> > +
> > + r->idiag_state = asoc->state;
> > + r->idiag_timer = SCTP_EVENT_TIMEOUT_T3_RTX;
> > + r->idiag_retrans = asoc->rtx_data_chunks;
> > +#define EXPIRES_IN_MS(tmo) DIV_ROUND_UP((tmo - jiffies) * 1000, HZ)
> > + r->idiag_expires =
> > + EXPIRES_IN_MS(asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX]);
> > +#undef EXPIRES_IN_MS
> > +
vvv
> > + if (nla_put_u8(skb, INET_DIAG_SHUTDOWN, sk->sk_shutdown))
> > + goto errout;
> > +
> > + /* IPv6 dual-stack sockets use inet->tos for IPv4 connections,
> > + * hence this needs to be included regardless of socket family.
> > + */
> > + if (ext & (1 << (INET_DIAG_TOS - 1)))
> > + if (nla_put_u8(skb, INET_DIAG_TOS, inet->tos) < 0)
> > + goto errout;
> > +
> > +#if IS_ENABLED(CONFIG_IPV6)
> > + if (r->idiag_family == AF_INET6) {
> > + if (ext & (1 << (INET_DIAG_TCLASS - 1)))
> > + if (nla_put_u8(skb, INET_DIAG_TCLASS,
> > + inet6_sk(sk)->tclass) < 0)
> > + goto errout;
> > +
> > + if (((1 << sk->sk_state) & (TCPF_LISTEN | TCPF_CLOSE)) &&
> > + nla_put_u8(skb, INET_DIAG_SKV6ONLY, ipv6_only_sock(sk)))
> > + goto errout;
> > + }
> > +#endif
> > +
> > + r->idiag_uid = from_kuid_munged(user_ns, sock_i_uid(sk));
> > + r->idiag_inode = sock_i_ino(sk);
> > +
> > + if (ext & (1 << (INET_DIAG_MEMINFO - 1))) {
> > + struct inet_diag_meminfo minfo = {
> > + .idiag_rmem = sk_rmem_alloc_get(sk),
> > + .idiag_wmem = sk->sk_wmem_queued,
> > + .idiag_fmem = sk->sk_forward_alloc,
> > + .idiag_tmem = sk_wmem_alloc_get(sk),
> > + };
> > +
>
> All this code looks familiar.
>
> Why inet_sk_diag_fill() is not used instead ?
Actually we have an issue here. idiag_tmem is using sk_wmem_alloc_get()
directly, but it shouldn't. SCTP supports using sndbuf per socket or
per assoc on that socket. We need an if and report the correct value,
as it's done in sctp_wspace().
For inet_ep_diag_fill, it's reporting an endpoint, so this is not needed
as we don't have this option in there.
> > + if (nla_put(skb, INET_DIAG_MEMINFO, sizeof(minfo), &minfo) < 0)
> > + goto errout;
> > + }
> > +
> > + if (ext & (1 << (INET_DIAG_SKMEMINFO - 1)))
> > + if (sock_diag_put_meminfo(sk, skb, INET_DIAG_SKMEMINFO))
> > + goto errout;
Same happens in sock_diag_put_meminfo().
I highlighted the section that would have been common to
inet_sk_diag_fill() if it wasn't for this wmem_alloc difference using
vvv and ^^^ marks. There is one or another common lines out of it. I
suggest we try to factor out this common code but only from within these
two functions in sctp_diag, leaving inet_diag alone for now, just until
this soak a bit more.
> > +
> > + if ((ext & (1 << (INET_DIAG_INFO - 1))) && handler->idiag_info_size) {
> > + attr = nla_reserve(skb, INET_DIAG_INFO,
> > + handler->idiag_info_size);
> > + if (!attr)
> > + goto errout;
> > +
> > + info = nla_data(attr);
> > + }
^^^
> > + infox.sctpinfo = (struct sctp_info *)info;
> > + infox.asoc = asoc;
> > + handler->idiag_get_info(sk, r, &infox);
> > +
> > + if (ext & (1 << (INET_DIAG_CONG - 1)))
> > + if (nla_put_string(skb, INET_DIAG_CONG, "reno") < 0)
> > + goto errout;
the above block is not common to inet_sk_diag_fill
> > +
> > + if (inet_sctp_fill_laddrs(skb, &asoc->base.bind_addr.address_list))
> > + goto errout;
> > +
> > + if (inet_sctp_fill_paddrs(skb, asoc))
> > + goto errout;
> > +
> > + nlmsg_end(skb, nlh);
> > + return 0;
> > +
> > +errout:
> > + nlmsg_cancel(skb, nlh);
> > + return -EMSGSIZE;
> > +}
> > +
> > +static int inet_ep_diag_fill(struct sock *sk, struct sctp_endpoint *ep,
> > + struct sk_buff *skb,
> > + const struct inet_diag_req_v2 *req,
> > + struct user_namespace *user_ns,
> > + u32 portid, u32 seq, u16 nlmsg_flags,
> > + const struct nlmsghdr *unlh)
> > +{
> > + const struct inet_sock *inet = inet_sk(sk);
> > + const struct inet_diag_handler *handler;
> > + int ext = req->idiag_ext;
> > + struct inet_diag_msg *r;
> > + struct nlmsghdr *nlh;
> > + struct nlattr *attr;
> > + void *info = NULL;
> > + struct sctp_infox infox;
> > +
> > + handler = inet_diag_get_handler(req->sdiag_protocol);
> > + BUG_ON(!handler);
> > +
> > + nlh = nlmsg_put(skb, portid, seq, unlh->nlmsg_type, sizeof(*r),
> > + nlmsg_flags);
> > + if (!nlh)
> > + return -EMSGSIZE;
> > +
> > + r = nlmsg_data(nlh);
> > + BUG_ON(!sk_fullsock(sk));
> > +
> > + inet_diag_msg_common_fill(r, sk);
> > + r->idiag_state = sk->sk_state;
> > + r->idiag_timer = 0;
> > + r->idiag_retrans = 0;
> > +
> > + if (nla_put_u8(skb, INET_DIAG_SHUTDOWN, sk->sk_shutdown))
> > + goto errout;
> > +
> > + /* IPv6 dual-stack sockets use inet->tos for IPv4 connections,
> > + * hence this needs to be included regardless of socket family.
> > + */
> > + if (ext & (1 << (INET_DIAG_TOS - 1)))
> > + if (nla_put_u8(skb, INET_DIAG_TOS, inet->tos) < 0)
> > + goto errout;
> > +
> > +#if IS_ENABLED(CONFIG_IPV6)
> > + if (r->idiag_family == AF_INET6) {
> > + if (ext & (1 << (INET_DIAG_TCLASS - 1)))
> > + if (nla_put_u8(skb, INET_DIAG_TCLASS,
> > + inet6_sk(sk)->tclass) < 0)
> > + goto errout;
> > +
> > + if (((1 << sk->sk_state) & (TCPF_LISTEN | TCPF_CLOSE)) &&
> > + nla_put_u8(skb, INET_DIAG_SKV6ONLY, ipv6_only_sock(sk)))
> > + goto errout;
> > + }
> > +#endif
> > +
> > + r->idiag_uid = from_kuid_munged(user_ns, sock_i_uid(sk));
> > + r->idiag_inode = sock_i_ino(sk);
> > +
> > + if (ext & (1 << (INET_DIAG_MEMINFO - 1))) {
> > + struct inet_diag_meminfo minfo = {
> > + .idiag_rmem = sk_rmem_alloc_get(sk),
> > + .idiag_wmem = sk->sk_wmem_queued,
> > + .idiag_fmem = sk->sk_forward_alloc,
> > + .idiag_tmem = sk_wmem_alloc_get(sk),
> > + };
> > +
>
> Again, looks a lot of duplication.
>
> Also you missed that INET_DIAG_MEMINFO is kind of obsolete,
> now we have sock_diag_put_meminfo()
>
>
> > + if (nla_put(skb, INET_DIAG_MEMINFO, sizeof(minfo), &minfo) < 0)
> > + goto errout;
> > + }
> > +
> > + if (ext & (1 << (INET_DIAG_SKMEMINFO - 1)))
> > + if (sock_diag_put_meminfo(sk, skb, INET_DIAG_SKMEMINFO))
> > + goto errout;
> > +
> > + if ((ext & (1 << (INET_DIAG_INFO - 1))) && handler->idiag_info_size) {
> > + attr = nla_reserve(skb, INET_DIAG_INFO,
> > + handler->idiag_info_size);
> > + if (!attr)
> > + goto errout;
> > +
> > + info = nla_data(attr);
> > + }
> > + infox.sctpinfo = (struct sctp_info *)info;
> > + infox.asoc = NULL;
> > + handler->idiag_get_info(sk, r, &infox);
> > +
> > + if (inet_sctp_fill_laddrs(skb, &ep->base.bind_addr.address_list))
> > + goto errout;
> > +
> > + nlmsg_end(skb, nlh);
> > + return 0;
> > +
> > +errout:
> > + nlmsg_cancel(skb, nlh);
> > + return -EMSGSIZE;
> > +}
> > +
> > +static size_t inet_assoc_attr_size(struct sctp_association *asoc)
> > +{
> > + int addrlen = sizeof(struct sockaddr_storage);
> > + int addrcnt = 0;
> > + struct sctp_sockaddr_entry *laddr;
> > +
> > + list_for_each_entry_rcu(laddr, &asoc->base.bind_addr.address_list,
> > + list)
> > + addrcnt++;
> > +
> > + return nla_total_size(sizeof(struct tcp_info))
>
> Are you sure you want to use tcp_info ???
>
> > + + nla_total_size(1) /* INET_DIAG_SHUTDOWN */
> > + + nla_total_size(1) /* INET_DIAG_TOS */
> > + + nla_total_size(1) /* INET_DIAG_TCLASS */
> > + + nla_total_size(addrlen * asoc->peer.transport_count)
> > + + nla_total_size(addrlen * addrcnt)
> > + + nla_total_size(sizeof(struct inet_diag_meminfo))
> > + + nla_total_size(sizeof(struct inet_diag_msg))
> > + + nla_total_size(sizeof(struct sctp_info))
> > + + 64;
> > +}
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Getting at the UDP headers from ->data_ready()
From: Willem de Bruijn @ 2016-04-11 21:18 UTC (permalink / raw)
To: David Howells; +Cc: Willem de Bruijn, Network Development
In-Reply-To: <19466.1460408649@warthog.procyon.org.uk>
On Mon, Apr 11, 2016 at 5:04 PM, David Howells <dhowells@redhat.com> wrote:
> Hi Willem,
>
> With regards to:
>
> commit 4d0fc73ebe94ac984a187f21fbf4f3a1ac846f5a
> Author: Willem de Bruijn <willemb@google.com>
> Date: Thu Apr 7 11:44:59 2016 -0400
>
> rxrpc: do not pull udp headers on receive
>
> Commit e6afc8ace6dd modified the udp receive path by pulling the udp
> header before queuing an skbuff onto the receive queue.
>
> Does that mean that I can no longer access the UDP header via udp_hdr(skb)
> from with the ->data_ready() handler?
>
> I'm guessing that's not actually the case since ip_hdr(skb) seems to work - or
> is that something I shouldn't be using since the part of the buffer containing
> the IP header might've been discarded?
The network and transport header pointers are still valid. Commit e6afc8ace6dd
only changes where skb->data points to. It does not discard the data between
skb->head and skb->data. This rxrpc follow-up patch fixes some offset
arithmetic to the payload, which is computed relative to skb->data.
There are other uses of ip_hdr and udp_hdr in udp_recvmsg and similar
recvmsg handlers for other protocols. For instance, in the source address
processing for recvfrom ("if (sin) { .. }")
^ permalink raw reply
* Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Or Gerlitz @ 2016-04-11 21:17 UTC (permalink / raw)
To: Saeed Mahameed, Matan Barak
Cc: Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Leon Romanovsky, Tal Alon
In-Reply-To: <1460405422-8654-3-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Mon, Apr 11, 2016 at 11:10 PM, Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
> Adding the needed mlx5_ifc hardware bits and structs
> for the following feature:
feature --> features
> * Add vport to steering commands for SRIOV ACL support
> * Add mlcr, pcmr and mcia registers for dump module EEPROM
> * Add support for FCS, baeacon led and disable_link bits to
> hca caps
> * Add CQE period mode bit in CQ context for CQE based CQ
> moderation support
> * Add umr SQ bit for fragmented memory registration
> * Add needed bits and caps for Striding RQ support
AFAIK, all the above are features will go through net-next, what made
you anticipate conflicts with linux-rdma?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Eric Dumazet @ 2016-04-11 21:14 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: lsf, netdev@vger.kernel.org, Brenden Blanco, James Bottomley,
linux-mm, Mel Gorman, Tom Herbert, lsf-pc, Mel Gorman,
Alexei Starovoitov, Alexander Duyck, Waskiewicz, PJ
In-Reply-To: <20160411214737.215c8e66@redhat.com>
On Mon, 2016-04-11 at 21:47 +0200, Jesper Dangaard Brouer wrote:
> On Mon, 11 Apr 2016 09:53:54 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Mon, 2016-04-11 at 18:19 +0200, Jesper Dangaard Brouer wrote:
> >
> > > Drivers also do tricks where they fallback to smaller order pages. E.g.
> > > lookup function mlx4_alloc_pages(). I've tried to simulate that
> > > function here:
> > > https://github.com/netoptimizer/prototype-kernel/blob/91d323fc53/kernel/mm/bench/page_bench01.c#L69
> >
> > We use order-0 pages on mlx4 at Google, as order-3 pages are very
> > dangerous for some kind of attacks...
>
> Interesting!
>
> > An out of order TCP packet can hold an order-3 pages, while claiming to
> > use 1.5 KBvia skb->truesize.
> >
> > order-0 only pages allow the page recycle trick used by Intel driver,
> > and we hardly see any page allocations in typical workloads.
>
> Yes, I looked at the Intel ixgbe drivers page recycle trick.
>
> It is actually quite cool, but code wise it is a little hard to
> follow. I started to look at the variant in i40e, specifically
> function i40e_clean_rx_irq_ps() explains it a bit more explicit.
>
>
> > While order-3 pages are 'nice' for friendly datacenter kind of
> > traffic, they also are a higher risk on hosts connected to the wild
> > Internet.
> >
> > Maybe I should upstream this patch ;)
>
> Definitely!
>
> Does this patch also include a page recycle trick? Else how do you get
> around the cost of allocating a single order-0 page?
>
Yes, we use the page recycle trick.
Obviously not on powerpc (or any arch with PAGE_SIZE >= 8192), but
definitely on x86.
--
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
* Getting at the UDP headers from ->data_ready()
From: David Howells @ 2016-04-11 21:04 UTC (permalink / raw)
To: willemb; +Cc: dhowells, netdev
Hi Willem,
With regards to:
commit 4d0fc73ebe94ac984a187f21fbf4f3a1ac846f5a
Author: Willem de Bruijn <willemb@google.com>
Date: Thu Apr 7 11:44:59 2016 -0400
rxrpc: do not pull udp headers on receive
Commit e6afc8ace6dd modified the udp receive path by pulling the udp
header before queuing an skbuff onto the receive queue.
Does that mean that I can no longer access the UDP header via udp_hdr(skb)
from with the ->data_ready() handler?
I'm guessing that's not actually the case since ip_hdr(skb) seems to work - or
is that something I shouldn't be using since the part of the buffer containing
the IP header might've been discarded?
David
^ permalink raw reply
* [PATCH] devlink: add missing install of header
From: Stephen Hemminger @ 2016-04-11 20:39 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, Stephen Hemminger
The new devlink.h in uapi was not being installed by
make headers_install
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
include/uapi/linux/Kbuild | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index b71fd0b..813ffb2e 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -96,6 +96,7 @@ header-y += cyclades.h
header-y += cycx_cfm.h
header-y += dcbnl.h
header-y += dccp.h
+header-y += devlink.h
header-y += dlmconstants.h
header-y += dlm_device.h
header-y += dlm.h
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 0/9] RxRPC: 2nd rewrite part 1
From: David Howells @ 2016-04-11 20:38 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, linux-afs, netdev, linux-kernel
In-Reply-To: <20160411.153511.1531573815825221764.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> Series applied, but I had to fix up some trailing whitespace (reported by
> GIT) by hand.
Okay, thanks.
David
^ permalink raw reply
* Re: [PATCH net-next 6/7] dsa: Rename phys_port_mask to user_port_mask
From: Andrew Lunn @ 2016-04-11 20:31 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <570C0328.5030108@gmail.com>
On Mon, Apr 11, 2016 at 01:03:52PM -0700, Florian Fainelli wrote:
> On 11/04/16 12:50, Andrew Lunn wrote:
> > The phys in phys_port_mask suggests this mask is about PHYs. In fact,
> > it means physical ports. Rename to user_port_mask, indicating user
> > ports of the switch, which is hopefully less confusing.
>
> Even though the change looks fine in principle, I am more worried about
> the difficulty for people to backport fixes because of the renaming
> happening here. How about "enabled_ports_mask" as a name?
I'm fine with that. Anything, so long as it does not contain phys.
> Did not
> Guenter had a helper function at some point which tested for (1 << port
> & ds->phys_port_mask)?
Maybe you are thinking of:
static inline bool dsa_is_port_initialized(struct dsa_switch *ds, int p)
{
return ds->phys_port_mask & (1 << p) && ds->ports[p];
}
So how about initialized_port_mask, although it is a bit long.
Andrew
^ permalink raw reply
* Re: [Lsf] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-11 20:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: lsf, Tom Herbert, Brenden Blanco, James Bottomley, linux-mm,
netdev@vger.kernel.org, lsf-pc, Alexei Starovoitov, brouer
In-Reply-To: <1460205278.6473.486.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 09 Apr 2016 05:34:38 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2016-04-09 at 11:11 +0200, Jesper Dangaard Brouer wrote:
>
> > Above code is okay. But do you think we also can get away with the same
> > trick we do with the SKB refcnf? Where we avoid an atomic operation if
> > refcnt==1.
> >
> > void kfree_skb(struct sk_buff *skb)
> > {
> > if (unlikely(!skb))
> > return;
> > if (likely(atomic_read(&skb->users) == 1))
> > smp_rmb();
> > else if (likely(!atomic_dec_and_test(&skb->users)))
> > return;
> > trace_kfree_skb(skb, __builtin_return_address(0));
> > __kfree_skb(skb);
> > }
> > EXPORT_SYMBOL(kfree_skb);
>
> No we can not use this trick this for pages :
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ec91698360b3818ff426488a1529811f7a7ab87f
>
If we have a page-pool recycle facility, then we could use the trick,
right? (As we know that get_page_unless_zero() cannot happen for pages
in the pool).
--
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
--
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
* [PATCH for-next 1/2] net/mlx5: Fix mlx5 ifc cmd_hca_cap bad offsets
From: Saeed Mahameed @ 2016-04-11 20:10 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Matan Barak, Leon Romanovsky, Tal Alon, Tariq Toukan,
Saeed Mahameed
In-Reply-To: <1460405422-8654-1-git-send-email-saeedm@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
All reserved fields after early_vf_enable are off by 1, since
early_vf_enable was not explicitly declared as array of size 1.
Reserved field before cqe_zip had a wrong size, it should
be 0x80 + 0x3f.
Fixes: b0844444590e ("net/mlx5_core: Introduce access function to read internal timer ")
Fixes: b4ff3a36d3e4 ("net/mlx5: Use offset based reserved field names in the IFC header file")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Matan Barak <matanb@mellanox.com>
---
include/linux/mlx5/mlx5_ifc.h | 107 +++++++++++++++++++++--------------------
1 files changed, 55 insertions(+), 52 deletions(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index c15b8a8..c300e74 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -750,21 +750,21 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 ets[0x1];
u8 nic_flow_table[0x1];
u8 eswitch_flow_table[0x1];
- u8 early_vf_enable;
- u8 reserved_at_1a8[0x2];
+ u8 early_vf_enable[0x1];
+ u8 reserved_at_1a9[0x2];
u8 local_ca_ack_delay[0x5];
u8 reserved_at_1af[0x6];
u8 port_type[0x2];
u8 num_ports[0x8];
- u8 reserved_at_1bf[0x3];
+ u8 reserved_at_1c0[0x3];
u8 log_max_msg[0x5];
- u8 reserved_at_1c7[0x4];
+ u8 reserved_at_1c8[0x4];
u8 max_tc[0x4];
- u8 reserved_at_1cf[0x6];
+ u8 reserved_at_1d0[0x6];
u8 rol_s[0x1];
u8 rol_g[0x1];
- u8 reserved_at_1d7[0x1];
+ u8 reserved_at_1d8[0x1];
u8 wol_s[0x1];
u8 wol_g[0x1];
u8 wol_a[0x1];
@@ -774,47 +774,47 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 wol_p[0x1];
u8 stat_rate_support[0x10];
- u8 reserved_at_1ef[0xc];
+ u8 reserved_at_1f0[0xc];
u8 cqe_version[0x4];
u8 compact_address_vector[0x1];
u8 reserved_at_200[0x3];
u8 ipoib_basic_offloads[0x1];
- u8 reserved_at_204[0xa];
+ u8 reserved_at_205[0xa];
u8 drain_sigerr[0x1];
u8 cmdif_checksum[0x2];
u8 sigerr_cqe[0x1];
- u8 reserved_at_212[0x1];
+ u8 reserved_at_213[0x1];
u8 wq_signature[0x1];
u8 sctr_data_cqe[0x1];
- u8 reserved_at_215[0x1];
+ u8 reserved_at_216[0x1];
u8 sho[0x1];
u8 tph[0x1];
u8 rf[0x1];
u8 dct[0x1];
- u8 reserved_at_21a[0x1];
+ u8 reserved_at_21b[0x1];
u8 eth_net_offloads[0x1];
u8 roce[0x1];
u8 atomic[0x1];
- u8 reserved_at_21e[0x1];
+ u8 reserved_at_21f[0x1];
u8 cq_oi[0x1];
u8 cq_resize[0x1];
u8 cq_moderation[0x1];
- u8 reserved_at_222[0x3];
+ u8 reserved_at_223[0x3];
u8 cq_eq_remap[0x1];
u8 pg[0x1];
u8 block_lb_mc[0x1];
- u8 reserved_at_228[0x1];
+ u8 reserved_at_229[0x1];
u8 scqe_break_moderation[0x1];
u8 reserved_at_22a[0x1];
u8 cd[0x1];
- u8 reserved_at_22c[0x1];
+ u8 reserved_at_22d[0x1];
u8 apm[0x1];
u8 vector_calc[0x1];
u8 reserved_at_22f[0x1];
u8 imaicl[0x1];
- u8 reserved_at_231[0x4];
+ u8 reserved_at_232[0x4];
u8 qkv[0x1];
u8 pkv[0x1];
u8 set_deth_sqpn[0x1];
@@ -824,98 +824,101 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 uc[0x1];
u8 rc[0x1];
- u8 reserved_at_23f[0xa];
+ u8 reserved_at_240[0xa];
u8 uar_sz[0x6];
- u8 reserved_at_24f[0x8];
+ u8 reserved_at_250[0x8];
u8 log_pg_sz[0x8];
u8 bf[0x1];
- u8 reserved_at_260[0x1];
+ u8 reserved_at_261[0x1];
u8 pad_tx_eth_packet[0x1];
- u8 reserved_at_262[0x8];
+ u8 reserved_at_263[0x8];
u8 log_bf_reg_size[0x5];
- u8 reserved_at_26f[0x10];
+ u8 reserved_at_270[0x10];
- u8 reserved_at_27f[0x10];
+ u8 reserved_at_280[0x10];
u8 max_wqe_sz_sq[0x10];
- u8 reserved_at_29f[0x10];
+ u8 reserved_at_2a0[0x10];
u8 max_wqe_sz_rq[0x10];
- u8 reserved_at_2bf[0x10];
+ u8 reserved_at_2c0[0x10];
u8 max_wqe_sz_sq_dc[0x10];
- u8 reserved_at_2df[0x7];
+ u8 reserved_at_2e0[0x7];
u8 max_qp_mcg[0x19];
- u8 reserved_at_2ff[0x18];
+ u8 reserved_at_300[0x18];
u8 log_max_mcg[0x8];
- u8 reserved_at_31f[0x3];
+ u8 reserved_at_320[0x3];
u8 log_max_transport_domain[0x5];
- u8 reserved_at_327[0x3];
+ u8 reserved_at_328[0x3];
u8 log_max_pd[0x5];
- u8 reserved_at_32f[0xb];
+ u8 reserved_at_330[0xb];
u8 log_max_xrcd[0x5];
- u8 reserved_at_33f[0x20];
+ u8 reserved_at_340[0x20];
- u8 reserved_at_35f[0x3];
+ u8 reserved_at_360[0x3];
u8 log_max_rq[0x5];
- u8 reserved_at_367[0x3];
+ u8 reserved_at_368[0x3];
u8 log_max_sq[0x5];
- u8 reserved_at_36f[0x3];
+ u8 reserved_at_370[0x3];
u8 log_max_tir[0x5];
- u8 reserved_at_377[0x3];
+ u8 reserved_at_378[0x3];
u8 log_max_tis[0x5];
u8 basic_cyclic_rcv_wqe[0x1];
- u8 reserved_at_380[0x2];
+ u8 reserved_at_381[0x2];
u8 log_max_rmp[0x5];
- u8 reserved_at_387[0x3];
+ u8 reserved_at_388[0x3];
u8 log_max_rqt[0x5];
- u8 reserved_at_38f[0x3];
+ u8 reserved_at_390[0x3];
u8 log_max_rqt_size[0x5];
- u8 reserved_at_397[0x3];
+ u8 reserved_at_398[0x3];
u8 log_max_tis_per_sq[0x5];
- u8 reserved_at_39f[0x3];
+ u8 reserved_at_3a0[0x3];
u8 log_max_stride_sz_rq[0x5];
- u8 reserved_at_3a7[0x3];
+ u8 reserved_at_3a8[0x3];
u8 log_min_stride_sz_rq[0x5];
- u8 reserved_at_3af[0x3];
+ u8 reserved_at_3b0[0x3];
u8 log_max_stride_sz_sq[0x5];
- u8 reserved_at_3b7[0x3];
+ u8 reserved_at_3b8[0x3];
u8 log_min_stride_sz_sq[0x5];
- u8 reserved_at_3bf[0x1b];
+ u8 reserved_at_3c0[0x1b];
u8 log_max_wq_sz[0x5];
u8 nic_vport_change_event[0x1];
- u8 reserved_at_3e0[0xa];
+ u8 reserved_at_3e1[0xa];
u8 log_max_vlan_list[0x5];
- u8 reserved_at_3ef[0x3];
+ u8 reserved_at_3f0[0x3];
u8 log_max_current_mc_list[0x5];
- u8 reserved_at_3f7[0x3];
+ u8 reserved_at_3f8[0x3];
u8 log_max_current_uc_list[0x5];
- u8 reserved_at_3ff[0x80];
+ u8 reserved_at_400[0x80];
- u8 reserved_at_47f[0x3];
+ u8 reserved_at_480[0x3];
u8 log_max_l2_table[0x5];
- u8 reserved_at_487[0x8];
+ u8 reserved_at_488[0x8];
u8 log_uar_page_sz[0x10];
- u8 reserved_at_49f[0x20];
+ u8 reserved_at_4a0[0x20];
u8 device_frequency_mhz[0x20];
u8 device_frequency_khz[0x20];
- u8 reserved_at_4ff[0x5f];
+
+ u8 reserved_at_500[0x80];
+
+ u8 reserved_at_580[0x3f];
u8 cqe_zip[0x1];
u8 cqe_zip_timeout[0x10];
u8 cqe_zip_max_num[0x10];
- u8 reserved_at_57f[0x220];
+ u8 reserved_at_5e0[0x220];
};
enum mlx5_flow_destination_type {
--
1.7.1
^ permalink raw reply related
* [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Saeed Mahameed @ 2016-04-11 20:10 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Matan Barak, Leon Romanovsky, Tal Alon, Saeed Mahameed
In-Reply-To: <1460405422-8654-1-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Adding the needed mlx5_ifc hardware bits and structs
for the following feature:
* Add vport to steering commands for SRIOV ACL support
* Add mlcr, pcmr and mcia registers for dump module EEPROM
* Add support for FCS, baeacon led and disable_link bits to
hca caps
* Add CQE period mode bit in CQ context for CQE based CQ
moderation support
* Add umr SQ bit for fragmented memory registration
* Add needed bits and caps for Striding RQ support
Signed-off-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
include/linux/mlx5/mlx5_ifc.h | 146 ++++++++++++++++++++++++++++++++++------
1 files changed, 124 insertions(+), 22 deletions(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index c300e74..4ce4ea4 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -513,7 +513,9 @@ struct mlx5_ifc_per_protocol_networking_offload_caps_bits {
u8 max_lso_cap[0x5];
u8 reserved_at_10[0x4];
u8 rss_ind_tbl_cap[0x4];
- u8 reserved_at_18[0x3];
+ u8 reg_umr_sq[0x1];
+ u8 scatter_fcs[0x1];
+ u8 reserved_at_1a[0x1];
u8 tunnel_lso_const_out_ip_id[0x1];
u8 reserved_at_1c[0x2];
u8 tunnel_statless_gre[0x1];
@@ -648,7 +650,7 @@ struct mlx5_ifc_vector_calc_cap_bits {
enum {
MLX5_WQ_TYPE_LINKED_LIST = 0x0,
MLX5_WQ_TYPE_CYCLIC = 0x1,
- MLX5_WQ_TYPE_STRQ = 0x2,
+ MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ = 0x2,
};
enum {
@@ -753,7 +755,11 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 early_vf_enable[0x1];
u8 reserved_at_1a9[0x2];
u8 local_ca_ack_delay[0x5];
- u8 reserved_at_1af[0x6];
+ u8 reserved_at_1af[0x2];
+ u8 ports_check[0x1];
+ u8 reserved_at_1b2[0x1];
+ u8 disable_link_up[0x1];
+ u8 beacon_led[0x1];
u8 port_type[0x2];
u8 num_ports[0x8];
@@ -778,7 +784,8 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 cqe_version[0x4];
u8 compact_address_vector[0x1];
- u8 reserved_at_200[0x3];
+ u8 striding_rq[0x1];
+ u8 reserved_at_201[0x2];
u8 ipoib_basic_offloads[0x1];
u8 reserved_at_205[0xa];
u8 drain_sigerr[0x1];
@@ -807,12 +814,12 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 block_lb_mc[0x1];
u8 reserved_at_229[0x1];
u8 scqe_break_moderation[0x1];
- u8 reserved_at_22a[0x1];
+ u8 cq_period_start_from_cqe[0x1];
u8 cd[0x1];
u8 reserved_at_22d[0x1];
u8 apm[0x1];
u8 vector_calc[0x1];
- u8 reserved_at_22f[0x1];
+ u8 umr_ptr_rlky[0x1];
u8 imaicl[0x1];
u8 reserved_at_232[0x4];
u8 qkv[0x1];
@@ -913,10 +920,10 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 reserved_at_500[0x80];
u8 reserved_at_580[0x3f];
- u8 cqe_zip[0x1];
+ u8 cqe_compression[0x1];
- u8 cqe_zip_timeout[0x10];
- u8 cqe_zip_max_num[0x10];
+ u8 cqe_compression_timeout[0x10];
+ u8 cqe_compression_max_num[0x10];
u8 reserved_at_5e0[0x220];
};
@@ -1000,7 +1007,13 @@ struct mlx5_ifc_wq_bits {
u8 reserved_at_118[0x3];
u8 log_wq_sz[0x5];
- u8 reserved_at_120[0x4e0];
+ u8 reserved_at_120[0x15];
+ u8 log_wqe_num_of_strides[0x3];
+ u8 two_byte_shift_en[0x1];
+ u8 reserved_at_139[0x4];
+ u8 log_wqe_stride_size[0x3];
+
+ u8 reserved_at_140[0x4c0];
struct mlx5_ifc_cmd_pas_bits pas[0];
};
@@ -2199,7 +2212,8 @@ struct mlx5_ifc_sqc_bits {
u8 flush_in_error_en[0x1];
u8 reserved_at_4[0x4];
u8 state[0x4];
- u8 reserved_at_c[0x14];
+ u8 reg_umr[0x1];
+ u8 reserved_at_d[0x13];
u8 reserved_at_20[0x8];
u8 user_index[0x18];
@@ -2247,7 +2261,8 @@ enum {
struct mlx5_ifc_rqc_bits {
u8 rlky[0x1];
- u8 reserved_at_1[0x2];
+ u8 reserved_at_1[0x1];
+ u8 scatter_fcs[0x1];
u8 vsd[0x1];
u8 mem_rq_type[0x4];
u8 state[0x4];
@@ -2604,6 +2619,11 @@ enum {
MLX5_CQC_ST_FIRED = 0xa,
};
+enum {
+ MLX5_CQ_PERIOD_MODE_START_FROM_EQE = 0x0,
+ MLX5_CQ_PERIOD_MODE_START_FROM_CQE = 0x1,
+};
+
struct mlx5_ifc_cqc_bits {
u8 status[0x4];
u8 reserved_at_4[0x4];
@@ -2612,8 +2632,8 @@ struct mlx5_ifc_cqc_bits {
u8 reserved_at_c[0x1];
u8 scqe_break_moderation_en[0x1];
u8 oi[0x1];
- u8 reserved_at_f[0x2];
- u8 cqe_zip_en[0x1];
+ u8 cq_period_mode[0x2];
+ u8 cqe_comp_en[0x1];
u8 mini_cqe_res_format[0x2];
u8 st[0x4];
u8 reserved_at_18[0x8];
@@ -2987,7 +3007,11 @@ struct mlx5_ifc_set_fte_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x40];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
+
+ u8 reserved_at_60[0x20];
u8 table_type[0x8];
u8 reserved_at_88[0x18];
@@ -5181,7 +5205,11 @@ struct mlx5_ifc_destroy_flow_table_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x40];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
+
+ u8 reserved_at_60[0x20];
u8 table_type[0x8];
u8 reserved_at_88[0x18];
@@ -5208,7 +5236,11 @@ struct mlx5_ifc_destroy_flow_group_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x40];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
+
+ u8 reserved_at_60[0x20];
u8 table_type[0x8];
u8 reserved_at_88[0x18];
@@ -5349,7 +5381,11 @@ struct mlx5_ifc_delete_fte_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x40];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
+
+ u8 reserved_at_60[0x20];
u8 table_type[0x8];
u8 reserved_at_88[0x18];
@@ -5795,7 +5831,11 @@ struct mlx5_ifc_create_flow_table_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x40];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
+
+ u8 reserved_at_60[0x20];
u8 table_type[0x8];
u8 reserved_at_88[0x18];
@@ -5839,7 +5879,11 @@ struct mlx5_ifc_create_flow_group_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x40];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
+
+ u8 reserved_at_60[0x20];
u8 table_type[0x8];
u8 reserved_at_88[0x18];
@@ -6372,6 +6416,17 @@ struct mlx5_ifc_ptys_reg_bits {
u8 reserved_at_1a0[0x60];
};
+struct mlx5_ifc_mlcr_reg_bits {
+ u8 reserved_at_0[0x8];
+ u8 local_port[0x8];
+ u8 reserved_at_10[0x20];
+
+ u8 beacon_duration[0x10];
+ u8 reserved_at_40[0x10];
+
+ u8 beacon_remain[0x10];
+};
+
struct mlx5_ifc_ptas_reg_bits {
u8 reserved_at_0[0x20];
@@ -6781,6 +6836,16 @@ struct mlx5_ifc_pamp_reg_bits {
u8 index_data[18][0x10];
};
+struct mlx5_ifc_pcmr_reg_bits {
+ u8 reserved_at_0[0x8];
+ u8 local_port[0x8];
+ u8 reserved_at_10[0x2e];
+ u8 fcs_cap[0x1];
+ u8 reserved_at_3f[0x1f];
+ u8 fcs_chk[0x1];
+ u8 reserved_at_5f[0x1];
+};
+
struct mlx5_ifc_lane_2_module_mapping_bits {
u8 reserved_at_0[0x6];
u8 rx_lane[0x2];
@@ -7117,6 +7182,7 @@ union mlx5_ifc_ports_control_registers_document_bits {
struct mlx5_ifc_pspa_reg_bits pspa_reg;
struct mlx5_ifc_ptas_reg_bits ptas_reg;
struct mlx5_ifc_ptys_reg_bits ptys_reg;
+ struct mlx5_ifc_mlcr_reg_bits mlcr_reg;
struct mlx5_ifc_pude_reg_bits pude_reg;
struct mlx5_ifc_pvlc_reg_bits pvlc_reg;
struct mlx5_ifc_slrg_reg_bits slrg_reg;
@@ -7150,7 +7216,11 @@ struct mlx5_ifc_set_flow_table_root_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x40];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
+
+ u8 reserved_at_60[0x20];
u8 table_type[0x8];
u8 reserved_at_88[0x18];
@@ -7181,7 +7251,9 @@ struct mlx5_ifc_modify_flow_table_in_bits {
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
- u8 reserved_at_40[0x20];
+ u8 other_vport[0x1];
+ u8 reserved_at_41[0xf];
+ u8 vport_number[0x10];
u8 reserved_at_60[0x10];
u8 modify_field_select[0x10];
@@ -7247,4 +7319,34 @@ struct mlx5_ifc_qtct_reg_bits {
u8 tclass[0x3];
};
+struct mlx5_ifc_mcia_reg_bits {
+ u8 l[0x1];
+ u8 reserved_at_1[0x7];
+ u8 module[0x8];
+ u8 reserved_at_10[0x8];
+ u8 status[0x8];
+
+ u8 i2c_device_address[0x8];
+ u8 page_number[0x8];
+ u8 device_address[0x10];
+
+ u8 reserved_at_40[0x10];
+ u8 size[0x10];
+
+ u8 reserved_at_60[0x20];
+
+ u8 dword_0[0x20];
+ u8 dword_1[0x20];
+ u8 dword_2[0x20];
+ u8 dword_3[0x20];
+ u8 dword_4[0x20];
+ u8 dword_5[0x20];
+ u8 dword_6[0x20];
+ u8 dword_7[0x20];
+ u8 dword_8[0x20];
+ u8 dword_9[0x20];
+ u8 dword_10[0x20];
+ u8 dword_11[0x20];
+};
+
#endif /* MLX5_IFC_H */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH for-next 0/2] mlx5_core: mlx5_ifc updates
From: Saeed Mahameed @ 2016-04-11 20:10 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Matan Barak, Leon Romanovsky, Tal Alon, Saeed Mahameed
Hi Dave and Doug
This series include mlx5_core updates for both net-next and rdma
trees for 4.7 kernel cycle. This is the only shared code planned
for 4.7 between rdma and net trees. Hopefully, this will prevent
future conflicts when merging between ib-next and net-next once
4.7 cycle is over and merge window is opened.
Both Mellanox rdma and net submissions will proceed once this series
is applied into both trees.
Future shared code will be sent to both maintainers as pull requests
from Mellanox's kernel.org tree.
We have included all the maintainers of respective drivers.
Kindly review the change and let us know in case of any review comments.
Saeed Mahameed (1):
net/mlx5: Update mlx5_ifc hardware features
Tariq Toukan (1):
net/mlx5: Fix mlx5 ifc cmd_hca_cap bad offsets
include/linux/mlx5/mlx5_ifc.h | 253 +++++++++++++++++++++++++++++------------
1 files changed, 179 insertions(+), 74 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 6/7] dsa: Rename phys_port_mask to user_port_mask
From: Florian Fainelli @ 2016-04-11 20:03 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Vivien Didelot
In-Reply-To: <1460404209-32083-7-git-send-email-andrew@lunn.ch>
On 11/04/16 12:50, Andrew Lunn wrote:
> The phys in phys_port_mask suggests this mask is about PHYs. In fact,
> it means physical ports. Rename to user_port_mask, indicating user
> ports of the switch, which is hopefully less confusing.
Even though the change looks fine in principle, I am more worried about
the difficulty for people to backport fixes because of the renaming
happening here. How about "enabled_ports_mask" as a name? Did not
Guenter had a helper function at some point which tested for (1 << port
& ds->phys_port_mask)?
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/dsa/bcm_sf2.c | 10 +++++-----
> drivers/net/dsa/mv88e6060.c | 2 +-
> include/net/dsa.h | 4 ++--
> net/dsa/dsa.c | 8 ++++----
> 4 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index 50caa525cda3..e1e8070fb9f9 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -160,7 +160,7 @@ static void bcm_sf2_imp_vlan_setup(struct dsa_switch *ds, int cpu_port)
> * the same VLAN.
> */
> for (i = 0; i < priv->hw_params.num_ports; i++) {
> - if (!((1 << i) & ds->phys_port_mask))
> + if (!((1 << i) & ds->user_port_mask))
> continue;
>
> reg = core_readl(priv, CORE_PORT_VLAN_CTL_PORT(i));
> @@ -1009,7 +1009,7 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
> /* Enable all valid ports and disable those unused */
> for (port = 0; port < priv->hw_params.num_ports; port++) {
> /* IMP port receives special treatment */
> - if ((1 << port) & ds->phys_port_mask)
> + if ((1 << port) & ds->user_port_mask)
> bcm_sf2_port_setup(ds, port, NULL);
> else if (dsa_is_cpu_port(ds, port))
> bcm_sf2_imp_setup(ds, port);
> @@ -1022,7 +1022,7 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
> * 7445D0, since 7445E0 disconnects the internal switch pseudo-PHY such
> * that we can use the regular SWITCH_MDIO master controller instead.
> *
> - * By default, DSA initializes ds->phys_mii_mask to ds->phys_port_mask
> + * By default, DSA initializes ds->phys_mii_mask to ds->user_port_mask
> * to have a 1:1 mapping between Port address and PHY address in order
> * to utilize the slave_mii_bus instance to read from Port PHYs. This is
> * not what we want here, so we initialize phys_mii_mask 0 to always
> @@ -1284,7 +1284,7 @@ static int bcm_sf2_sw_suspend(struct dsa_switch *ds)
> * bcm_sf2_sw_setup
> */
> for (port = 0; port < DSA_MAX_PORTS; port++) {
> - if ((1 << port) & ds->phys_port_mask ||
> + if ((1 << port) & ds->user_port_mask ||
> dsa_is_cpu_port(ds, port))
> bcm_sf2_port_disable(ds, port, NULL);
> }
> @@ -1308,7 +1308,7 @@ static int bcm_sf2_sw_resume(struct dsa_switch *ds)
> bcm_sf2_gphy_enable_set(ds, true);
>
> for (port = 0; port < DSA_MAX_PORTS; port++) {
> - if ((1 << port) & ds->phys_port_mask)
> + if ((1 << port) & ds->user_port_mask)
> bcm_sf2_port_setup(ds, port, NULL);
> else if (dsa_is_cpu_port(ds, port))
> bcm_sf2_imp_setup(ds, port);
> diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
> index adb608ccd9aa..0ba0d413cf73 100644
> --- a/drivers/net/dsa/mv88e6060.c
> +++ b/drivers/net/dsa/mv88e6060.c
> @@ -170,7 +170,7 @@ static int mv88e6060_setup_port(struct dsa_switch *ds, int p)
> REG_WRITE(addr, PORT_VLAN_MAP,
> ((p & 0xf) << PORT_VLAN_MAP_DBNUM_SHIFT) |
> (dsa_is_cpu_port(ds, p) ?
> - ds->phys_port_mask :
> + ds->user_port_mask :
> BIT(ds->dst->cpu_port)));
>
> /* Port Association Vector: when learning source addresses
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 165c2e10615c..b36c2a5c206f 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -167,7 +167,7 @@ struct dsa_switch {
> * Slave mii_bus and devices for the individual ports.
> */
> u32 dsa_port_mask;
> - u32 phys_port_mask;
> + u32 user_port_mask;
> u32 phys_mii_mask;
> struct mii_bus *slave_mii_bus;
> struct net_device *ports[DSA_MAX_PORTS];
> @@ -185,7 +185,7 @@ static inline bool dsa_is_dsa_port(struct dsa_switch *ds, int p)
>
> static inline bool dsa_is_port_initialized(struct dsa_switch *ds, int p)
> {
> - return ds->phys_port_mask & (1 << p) && ds->ports[p];
> + return ds->user_port_mask & (1 << p) && ds->ports[p];
> }
>
> static inline u8 dsa_upstream_port(struct dsa_switch *ds)
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 14bf12f637d2..20293d1a5a93 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -246,7 +246,7 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
> } else if (!strcmp(name, "dsa")) {
> ds->dsa_port_mask |= 1 << i;
> } else {
> - ds->phys_port_mask |= 1 << i;
> + ds->user_port_mask |= 1 << i;
> }
> valid_name_found = true;
> }
> @@ -259,7 +259,7 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
> /* Make the built-in MII bus mask match the number of ports,
> * switch drivers can override this later
> */
> - ds->phys_mii_mask = ds->phys_port_mask;
> + ds->phys_mii_mask = ds->user_port_mask;
>
> /*
> * If the CPU connects to this switch, set the switch tree
> @@ -325,7 +325,7 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
> * Create network devices for physical switch ports.
> */
> for (i = 0; i < DSA_MAX_PORTS; i++) {
> - if (!(ds->phys_port_mask & (1 << i)))
> + if (!(ds->user_port_mask & (1 << i)))
> continue;
>
> ret = dsa_slave_create(ds, parent, i, pd->port_names[i]);
> @@ -435,7 +435,7 @@ static void dsa_switch_destroy(struct dsa_switch *ds)
>
> /* Destroy network devices for physical switch ports. */
> for (port = 0; port < DSA_MAX_PORTS; port++) {
> - if (!(ds->phys_port_mask & (1 << port)))
> + if (!(ds->user_port_mask & (1 << port)))
> continue;
>
> if (!ds->ports[port])
>
--
Florian
^ permalink raw reply
* [PATCH net-next 7/7] dsa: mv88e6xxx: Use bus in mv88e6xxx_lookup_name()
From: Andrew Lunn @ 2016-04-11 19:50 UTC (permalink / raw)
To: David Miller; +Cc: Florian Fainelli, netdev, Vivien Didelot, Andrew Lunn
In-Reply-To: <1460404209-32083-1-git-send-email-andrew@lunn.ch>
mv88e6xxx_lookup_name() returns the model name of a switch at a given
address on an MII bus. Using mii_bus to identify the bus rather than
the host device is more logical, so change the parameter.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
v2: Check bus is valid before using it.
---
drivers/net/dsa/mv88e6xxx.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index c242ffd8eb09..9985a0cf31f1 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3068,11 +3068,10 @@ int mv88e6xxx_get_temp_alarm(struct dsa_switch *ds, bool *alarm)
}
#endif /* CONFIG_NET_DSA_HWMON */
-static char *mv88e6xxx_lookup_name(struct device *host_dev, int sw_addr,
+static char *mv88e6xxx_lookup_name(struct mii_bus *bus, int sw_addr,
const struct mv88e6xxx_switch_id *table,
unsigned int num)
{
- struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
int i, ret;
if (!bus)
@@ -3090,7 +3089,8 @@ static char *mv88e6xxx_lookup_name(struct device *host_dev, int sw_addr,
/* Look up only the product number */
for (i = 0; i < num; ++i) {
if (table[i].id == (ret & PORT_SWITCH_ID_PROD_NUM_MASK)) {
- dev_warn(host_dev, "unknown revision %d, using base switch 0x%x\n",
+ dev_warn(&bus->dev,
+ "unknown revision %d, using base switch 0x%x\n",
ret & PORT_SWITCH_ID_REV_MASK,
ret & PORT_SWITCH_ID_PROD_NUM_MASK);
return table[i].name;
@@ -3106,9 +3106,13 @@ char *mv88e6xxx_drv_probe(struct device *dsa_dev, struct device *host_dev,
unsigned int num)
{
struct mv88e6xxx_priv_state *ps;
+ struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
char *name;
- name = mv88e6xxx_lookup_name(host_dev, sw_addr, table, num);
+ if (!bus)
+ return NULL;
+
+ name = mv88e6xxx_lookup_name(bus, sw_addr, table, num);
if (name) {
ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
if (!ps)
--
2.7.0
^ permalink raw reply related
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