* Re: [RFC] RESEND - rdmatool - tool for RDMA users
From: Jason Gunthorpe @ 2017-01-18 18:31 UTC (permalink / raw)
To: Or Gerlitz
Cc: Leon Romanovsky, Ariel Almog, linux-rdma@vger.kernel.org,
Linux Netdev List
In-Reply-To: <CAJ3xEMiR1+NGghUZJ6aGq+=xTdOHU5Ph-BcPii5OUB8dT4Vq-A@mail.gmail.com>
On Wed, Jan 18, 2017 at 07:50:26PM +0200, Or Gerlitz wrote:
> On Wed, Jan 18, 2017 at 7:33 PM, Leon Romanovsky wrote:
> > On Wed, Jan 18, 2017 at 06:48:21PM +0200, Or Gerlitz wrote:
> >> On Wed, Jan 18, 2017 at 5:19 PM, Ariel Almog
> >> <arielalmogworkemails@gmail.com> wrote:
>
> >>> As of today, there is no single, simple, tool that allows monitoring
> >>> and configuration of RDMA stack.
>
> >> Before tool, what kernel UAPI you thought to use?
>
> > I'm aware of the following options:
> > 1) netlink
> > 2) RDMA ABI https://www.spinics.net/lists/linux-rdma/msg43960.html
> > 3) ioctl
> > 4) write/read
> >
> > The items 1 and 2 are preferred options and one of the main goals
> > for this RFC is to chose between them.
> >
> > For example, RDMA ABI has native support of querying and discovering
> > device capabilities via merge tree feature.
>
> To make it clear, when you wrote ABI in your initial email, I tend to
> think it was sort of unclear to the netdev crowd that you are talking
> on new UAPI which is now under the works for the IB subsystem, so with
> my netdev community member hat, I got confused... anyway
I think it depends on what this tool is supposed to cover, but based
on the description, I would start with netlink-only.
The only place verbs covers a similar ground is in 'device
capabilities' - for some of that you might want to open a new-uAPI
verbs fd, but even the capability data from that would not be
totally offensive to be accessed over netlink.
IMHO netlink should cover almost everything found in sysfs today.
I'm also deeply skeptical about driver-specific stuff at this layer,
that sounds like a way to make a big mess.
Jason
^ permalink raw reply
* Re: [PATCH] net: fec: Fixed panic problem with non-tso
From: Pravin Shelar @ 2017-01-18 18:18 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ashizuka, Yuusuke, Andy Duan, netdev@vger.kernel.org,
Pravin B Shelar
In-Reply-To: <1484714132.13165.92.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, Jan 17, 2017 at 8:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2017-01-17 at 20:21 -0800, Eric Dumazet wrote:
>> On Wed, 2017-01-18 at 03:12 +0000, Ashizuka, Yuusuke wrote:
>>
>> > indeed.
>> >
>> > In the case of TSO with i.MX6 system (highmem enabled) with 2GB memory,
>> > "this_frag->page.p" did not become highmem area.
>> > (We confirmed by transferring about 100MB of files)
>> >
>> > However, in the case of non-tso on an i.MX6 system with 2GB of memory,
>> > "this_frag->page.p" may become a highmem area.
>> > (Occurred with approximately 2MB of file transfer)
>> >
>> > For non-tso only, I do not know the reason why "this_frag-> page.p"
>> > in this driver shows highmem area.
>>
>> This worries me, since this driver does not set NETIF_F_HIGHDMA in its
>> features.
>>
>> No packet should be given to this driver with a highmem fragment
>>
>> Check is done in illegal_highdma() in net/core/dev.c
>
> This used to work.
>
> I suspect commit ec5f061564238892005257c83565a0b58ec79295
> ("net: Kill link between CSUM and SG features.")
>
> added this bug.
>
> Can you try this hot fix :
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index ad5959e561166f445bdd9d7260652a338f74cfea..073b832b945257dba9ed47f4bf875605225effc9 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2773,9 +2773,9 @@ static netdev_features_t harmonize_features(struct sk_buff *skb,
> if (skb->ip_summed != CHECKSUM_NONE &&
> !can_checksum_protocol(features, type)) {
> features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
> - } else if (illegal_highdma(skb->dev, skb)) {
> - features &= ~NETIF_F_SG;
> }
> + if (illegal_highdma(skb->dev, skb))
> + features &= ~NETIF_F_SG;
>
> return features;
> }
Right, this high mem check should be decoupled from csum check.
Thanks,
Pravin.
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Eric Dumazet @ 2017-01-18 18:16 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Alexey Kodanev, Eric Dumazet, David Miller, netdev,
Vasily Isaenko, Neal Cardwell
In-Reply-To: <CAK6E8=fL+Gf_uqxALxX8iT7Ew9sxZA_+Ncaa+nh2ZWMkej154w@mail.gmail.com>
On Wed, Jan 18, 2017 at 10:13 AM, Yuchung Cheng <ycheng@google.com> wrote:
> On Wed, Jan 18, 2017 at 9:35 AM, Eric Dumazet <edumazet@google.com> wrote:
>>
>> On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
>> <alexey.kodanev@oracle.com> wrote:
>> > Hi Eric,
>> >
>> > On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
>> >
>>
>> > Looks like max_window not correctly initialized for tfo sockets.
>> > On my test machine it has set to '5592320' in tcp_fastopen_create_child().
>> >
>> > This diff fixes the issue, the question: is this the right place to do it?
>> >
>> > diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
>> > index 4e777a3..33ed508 100644
>> > --- a/net/ipv4/tcp_fastopen.c
>> > +++ b/net/ipv4/tcp_fastopen.c
>> > @@ -206,6 +206,8 @@ static struct sock *tcp_fastopen_create_child(struct
>> > sock *sk,
>> > */
>> > tp->snd_wnd = ntohs(tcp_hdr(skb)->window);
>> >
>> > + tp->max_window = tp->snd_wnd;
>> > +
>>
>> Excellent catch. Let me test our regression tests with this.
> Indeed nice catch. Thanks for the investigative work!
>
We do have 2 failures, but tests might have depended on undocumented behavior
(For googlers :
Ran 211 tests: 209 passing, 0 flaky 2 failing
Sponge: http://sponge/f1575065-6e1c-4514-bced-9167ce56d2ee
)
Please Alexey submit an official patch, thanks a lot !
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Yuchung Cheng @ 2017-01-18 18:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Kodanev, Eric Dumazet, David Miller, netdev,
Vasily Isaenko, Neal Cardwell
In-Reply-To: <CANn89iJn+fC-mMCskczXupj=yhvDijYEn-_NeCphuG8roNCygA@mail.gmail.com>
On Wed, Jan 18, 2017 at 9:35 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
> <alexey.kodanev@oracle.com> wrote:
> > Hi Eric,
> >
> > On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
> >
>
> > Looks like max_window not correctly initialized for tfo sockets.
> > On my test machine it has set to '5592320' in tcp_fastopen_create_child().
> >
> > This diff fixes the issue, the question: is this the right place to do it?
> >
> > diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
> > index 4e777a3..33ed508 100644
> > --- a/net/ipv4/tcp_fastopen.c
> > +++ b/net/ipv4/tcp_fastopen.c
> > @@ -206,6 +206,8 @@ static struct sock *tcp_fastopen_create_child(struct
> > sock *sk,
> > */
> > tp->snd_wnd = ntohs(tcp_hdr(skb)->window);
> >
> > + tp->max_window = tp->snd_wnd;
> > +
>
> Excellent catch. Let me test our regression tests with this.
Indeed nice catch. Thanks for the investigative work!
>
> Thanks !
^ permalink raw reply
* Re: [PATCH 0/6 net-next][V4] Rework inet_csk_get_port
From: David Miller @ 2017-01-18 18:09 UTC (permalink / raw)
To: jbacik; +Cc: hannes, kraigatgoog, eric.dumazet, tom, netdev, kernel-team
In-Reply-To: <20170117155106.22637-1-jbacik@fb.com>
From: Josef Bacik <jbacik@fb.com>
Date: Tue, 17 Jan 2017 07:51:00 -0800
> V3->V4:
> -Removed the random include of addrconf.h that is no longer needed.
>
> V2->V3:
> -Dropped the fastsock from the tb and instead just carry the saddrs, family, and
> ipv6 only flag.
> -Reworked the helper functions to deal with this change so I could still use
> them when checking the fast path.
> -Killed tb->num_owners as per Eric's request.
> -Attached a reproducer to the bottom of this email.
>
> V1->V2:
> -Added a new patch 'inet: collapse ipv4/v6 rcv_saddr_equal functions into one'
> at Hannes' suggestion.
> -Dropped ->bind_conflict and just use the new helper.
> -Fixed a compile bug from the original ->bind_conflict patch.
>
> The original description of the series follows
...
Series applied, thanks!
^ permalink raw reply
* [PATCH net-next] bpf: add bpf_probe_read_str helper
From: Gianluca Borello @ 2017-01-18 17:55 UTC (permalink / raw)
To: davem; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev, Gianluca Borello
Provide a simple helper with the same semantics of strncpy_from_unsafe():
int bpf_probe_read_str(void *dst, int size, const void *unsafe_addr)
This gives more flexibility to a bpf program. A typical use case is
intercepting a file name during sys_open(). The current approach is:
SEC("kprobe/sys_open")
void bpf_sys_open(struct pt_regs *ctx)
{
char buf[PATHLEN]; // PATHLEN is defined to 256
bpf_probe_read(buf, sizeof(buf), ctx->di);
/* consume buf */
}
This is suboptimal because the size of the string needs to be estimated
at compile time, causing more memory to be copied than often necessary,
and can become more problematic if further processing on buf is done,
for example by pushing it to userspace via bpf_perf_event_output(),
since the real length of the string is unknown and the entire buffer
must be copied (and defining an unrolled strnlen() inside the bpf
program is a very inefficient and unfeasible approach).
With the new helper, the code can easily operate on the actual string
length rather than the buffer size:
SEC("kprobe/sys_open")
void bpf_sys_open(struct pt_regs *ctx)
{
char buf[PATHLEN]; // PATHLEN is defined to 256
int res = bpf_probe_read_str(buf, sizeof(buf), ctx->di);
/* consume buf, for example push it to userspace via
* bpf_perf_event_output(), but this time we can use
* res (the string length) as event size, after checking
* its boundaries.
*/
}
Another useful use case is when parsing individual process arguments or
individual environment variables navigating current->mm->arg_start and
current->mm->env_start: using this helper and the return value, one can
quickly iterate at the right offset of the memory area.
The code changes simply leverage the already existent
strncpy_from_unsafe() kernel function, which is safe to be called from a
bpf program as it is used in bpf_trace_printk().
Signed-off-by: Gianluca Borello <g.borello@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/uapi/linux/bpf.h | 15 ++++++++++++++-
kernel/trace/bpf_trace.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 0eb0e87dbe9f..54a5894bb4ea 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -430,6 +430,18 @@ union bpf_attr {
* @xdp_md: pointer to xdp_md
* @delta: An positive/negative integer to be added to xdp_md.data
* Return: 0 on success or negative on error
+ *
+ * int bpf_probe_read_str(void *dst, int size, const void *unsafe_ptr)
+ * Copy a NUL terminated string from unsafe address. In case the string
+ * length is smaller than size, the target is not padded with further NUL
+ * bytes. In case the string length is larger than size, just count-1
+ * bytes are copied and the last byte is set to NUL.
+ * @dst: destination address
+ * @size: maximum number of bytes to copy, including the trailing NUL
+ * @unsafe_ptr: unsafe address
+ * Return:
+ * > 0 length of the string including the trailing NUL on success
+ * < 0 error
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -476,7 +488,8 @@ union bpf_attr {
FN(set_hash_invalid), \
FN(get_numa_node_id), \
FN(skb_change_head), \
- FN(xdp_adjust_head),
+ FN(xdp_adjust_head), \
+ FN(probe_read_str),
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index c22a961d1a42..424daa4586d1 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -395,6 +395,36 @@ static const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
.arg2_type = ARG_ANYTHING,
};
+BPF_CALL_3(bpf_probe_read_str, void *, dst, u32, size,
+ const void *, unsafe_ptr)
+{
+ int ret;
+
+ /*
+ * The strncpy_from_unsafe() call will likely not fill the entire
+ * buffer, but that's okay in this circumstance as we're probing
+ * arbitrary memory anyway similar to bpf_probe_read() and might
+ * as well probe the stack. Thus, memory is explicitly cleared
+ * only in error case, so that improper users ignoring return
+ * code altogether don't copy garbage; otherwise length of string
+ * is returned that can be used for bpf_perf_event_output() et al.
+ */
+ ret = strncpy_from_unsafe(dst, unsafe_ptr, size);
+ if (unlikely(ret < 0))
+ memset(dst, 0, size);
+
+ return ret;
+}
+
+static const struct bpf_func_proto bpf_probe_read_str_proto = {
+ .func = bpf_probe_read_str,
+ .gpl_only = true,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_UNINIT_MEM,
+ .arg2_type = ARG_CONST_SIZE,
+ .arg3_type = ARG_ANYTHING,
+};
+
static const struct bpf_func_proto *tracing_func_proto(enum bpf_func_id func_id)
{
switch (func_id) {
@@ -432,6 +462,8 @@ static const struct bpf_func_proto *tracing_func_proto(enum bpf_func_id func_id)
return &bpf_current_task_under_cgroup_proto;
case BPF_FUNC_get_prandom_u32:
return &bpf_get_prandom_u32_proto;
+ case BPF_FUNC_probe_read_str:
+ return &bpf_probe_read_str_proto;
default:
return NULL;
}
--
2.11.0
^ permalink raw reply related
* Re: [RFC] RESEND - rdmatool - tool for RDMA users
From: Or Gerlitz @ 2017-01-18 17:50 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Ariel Almog, linux-rdma@vger.kernel.org, Linux Netdev List
In-Reply-To: <20170118173327.GF32481@mtr-leonro.local>
On Wed, Jan 18, 2017 at 7:33 PM, Leon Romanovsky wrote:
> On Wed, Jan 18, 2017 at 06:48:21PM +0200, Or Gerlitz wrote:
>> On Wed, Jan 18, 2017 at 5:19 PM, Ariel Almog
>> <arielalmogworkemails@gmail.com> wrote:
>>> As of today, there is no single, simple, tool that allows monitoring
>>> and configuration of RDMA stack.
>> Before tool, what kernel UAPI you thought to use?
> I'm aware of the following options:
> 1) netlink
> 2) RDMA ABI https://www.spinics.net/lists/linux-rdma/msg43960.html
> 3) ioctl
> 4) write/read
>
> The items 1 and 2 are preferred options and one of the main goals
> for this RFC is to chose between them.
>
> For example, RDMA ABI has native support of querying and discovering
> device capabilities via merge tree feature.
To make it clear, when you wrote ABI in your initial email, I tend to
think it was sort of unclear to the netdev crowd that you are talking
on new UAPI which is now under the works for the IB subsystem, so with
my netdev community member hat, I got confused... anyway
>> > It is a good point to highlight the similarity to ethtool. It manages
>> > net_device, while rdmatool will manage RDMA stack.
ethtool is likely to be ported to use netlink somewhere in the 21st century BTW
>> What's wrong with the RDMA netlink infrastructure?! it's there for
>> years and used
>> for various cases by MLNX, did you look on the code?
> Nothing wrong, it is one of the valuable options and will be used if
> community decides to put this tool under iproute2/ethtool umbrella.
yeah, using netlink sounds good to me, and where you package/maintain
the tool is of 2nd order, 1st decide what UAPI you wonna use. So far
netlink was good for what bunch of use-cases needed.
Or.
>> cea05ea IB/core: Add flow control to the portmapper netlink calls
>> ae43f82 IB/core: Add IP to GID netlink offload
>> 2ca546b IB/sa: Route SA pathrecord query through netlink
>> 753f618 RDMA/cma: Add support for netlink statistics export
>> b2cbae2 RDMA: Add netlink infrastructure
^ permalink raw reply
* Re: [PATCH net-next] net: Remove usage of net_device last_rx member
From: Jay Vosburgh @ 2017-01-18 17:39 UTC (permalink / raw)
To: Tobias Klauser
Cc: devel, Eric Dumazet, netdev, b.a.t.m.a.n, linux-m68k,
intel-wired-lan, Veaceslav Falico, Andy Gospodarek, Mirko Lindner
In-Reply-To: <20170118164501.1934-1-tklauser@distanz.ch>
Tobias Klauser <tklauser@distanz.ch> wrote:
>The network stack no longer uses the last_rx member of struct net_device
>since the bonding driver switched to use its own private last_rx in
>commit 9f242738376d ("bonding: use last_arp_rx in slave_last_rx()").
>
>However, some drivers still (ab)use the field for their own purposes and
>some driver just update it without actually using it.
>
>Previously, there was an accompanying comment for the last_rx member
>added in commit 4dc89133f49b ("net: add a comment on netdev->last_rx")
>which asked drivers not to update is, unless really needed. However,
>this commend was removed in commit f8ff080dacec ("bonding: remove
>useless updating of slave->dev->last_rx"), so some drivers added later
>on still did update last_rx.
>
>Remove all usage of last_rx and switch three drivers (sky2, atp and
>smc91c92_cs) which actually read and write it to use their own private
>copy in netdev_priv.
>
>Compile-tested with allyesconfig and allmodconfig on x86 and arm.
Reviewed-by: Jay Vosburgh <jay.vosburgh@canonical.com>
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Eric Dumazet @ 2017-01-18 17:35 UTC (permalink / raw)
To: Alexey Kodanev
Cc: Eric Dumazet, David Miller, netdev, Vasily Isaenko, Neal Cardwell,
Yuchung Cheng
In-Reply-To: <3dbbcda8-ce79-641c-cf3b-21f41c563939@oracle.com>
On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
<alexey.kodanev@oracle.com> wrote:
> Hi Eric,
>
> On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
>
> Looks like max_window not correctly initialized for tfo sockets.
> On my test machine it has set to '5592320' in tcp_fastopen_create_child().
>
> This diff fixes the issue, the question: is this the right place to do it?
>
> diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
> index 4e777a3..33ed508 100644
> --- a/net/ipv4/tcp_fastopen.c
> +++ b/net/ipv4/tcp_fastopen.c
> @@ -206,6 +206,8 @@ static struct sock *tcp_fastopen_create_child(struct
> sock *sk,
> */
> tp->snd_wnd = ntohs(tcp_hdr(skb)->window);
>
> + tp->max_window = tp->snd_wnd;
> +
Excellent catch. Let me test our regression tests with this.
Thanks !
^ permalink raw reply
* Re: [RFC] RESEND - rdmatool - tool for RDMA users
From: Leon Romanovsky @ 2017-01-18 17:33 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Ariel Almog, linux-rdma@vger.kernel.org, Linux Netdev List
In-Reply-To: <CAJ3xEMgO496ctgCUp1sW=-pCUyniy7LZb8hSkyNeYsJ1V4aVwg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3155 bytes --]
On Wed, Jan 18, 2017 at 06:48:21PM +0200, Or Gerlitz wrote:
> On Wed, Jan 18, 2017 at 5:19 PM, Ariel Almog
> <arielalmogworkemails@gmail.com> wrote:
> > General
> > *******
> > As of today, there is no single, simple, tool that allows monitoring
> > and configuration of RDMA stack.
>
> Before tool, what kernel UAPI you thought to use?
I'm aware of the following options:
1) netlink
2) RDMA ABI https://www.spinics.net/lists/linux-rdma/msg43960.html
3) ioctl
4) write/read
The items 1 and 2 are preferred options and one of the main goals
for this RFC is to chose between them.
For example, RDMA ABI has native support of querying and discovering
device capabilities via merge tree feature.
https://github.com/matanb10/linux/commit/61aaa4cae1281f6bb32e261f0b8aad489db764ac
>
>
> > rdmatool will provide standard, provider agnostic, user interface.
> > RDMA user can use this interface to
> > * Query RDMA device capabilities
> > * Query RDMA device status and current open resources
> > * Fetching RDMA statistics
> > * Configure RDMA device
> >
> > The rdmatool will have the ability to control RDMA stack which
> > includes the ib_device and RDMA protocol params.
> >
> > It is a good point to highlight the similarity to ethtool. It manages
> > net_device, while rdmatool will manage RDMA stack.
> >
> > As a proposal, it is appealing to have a similar design to ethtool for
> > rdmatool too. As ethtool, it should contain user space part, kernel
> > handler and vendor specific handler(s).
> >
> > Another tool which allows similar functionality is iproute2. Iproute2
> > allows user space tools to configure and query transport, network and
> > link layer. The advantages of using iproute2 is the reuse of existing
> > tool and familiar interface in addition to the wide spreading of this tool.
> >
> > As start point of the discussion, we would like to propose two
> > implementation options for the rdmatool:
> > (1) Build a tool using ABI interface. This will be a RDMA tool
> > which will be distributed as part of RDMA package
> > (2) Enhancing iproute2 to include rdmatool functionality
> >
> > Our opinion is that the new ABI interface provides vast functionality and
> > it will be a waste to use other interface for the same functionality.
> > Each of the proposed implementation above have their advantages, and we
> > would like to hear your opinion regarding this direction.
>
> > I’m posting this RFC in both netdev and linux-rdma communities in
> > order to get feedback on this topic.
>
> What's wrong with the RDMA netlink infrastructure?! it's there for
> years and used
> for various cases by MLNX, did you look on the code?
Nothing wrong, it is one of the valuable options and will be used if
community decides to put this tool under iproute2/ethtool umbrella.
>
> cea05ea IB/core: Add flow control to the portmapper netlink calls
> ae43f82 IB/core: Add IP to GID netlink offload
> 2ca546b IB/sa: Route SA pathrecord query through netlink
> 753f618 RDMA/cma: Add support for netlink statistics export
> b2cbae2 RDMA: Add netlink infrastructure
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] macb: Common code to enable ptp support for SAMA5Dx platforms.
From: Nicolas Ferre @ 2017-01-18 17:32 UTC (permalink / raw)
To: Andrei Pistirica, netdev, linux-kernel, linux-arm-kernel, davem,
harinikatakamlinux, harini.katakam, richardcochran, rafalo
Cc: punnaia, michals, anirudh, boris.brezillon, alexandre.belloni,
tbultel
In-Reply-To: <1484758673-8694-1-git-send-email-andrei.pistirica@microchip.com>
Le 18/01/2017 à 09:57, Andrei Pistirica a écrit :
> This patch does the following:
> - add GEM-PTP interface
> - registers and bitfields for TSU are named according to SAMA5Dx data sheet
> - PTP support based on platform capability
The $subject will certainly never match reality, sadly "enable ptp
support for SAMA5Dx platforms". So, you'd better change it.
(no "." at the end BTW).
> Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
> ---
> This is just the common code for GEM-PTP support. Code is based on the comments
> related to the following patch series:
> - [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM.
> - [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx platforms.
>
> Note: Patch on net-next: January 18.
>
> Rafal/Harini, you can continue the work for GME-GXL.
>
> drivers/net/ethernet/cadence/macb.c | 33 ++++++++++++++++-
> drivers/net/ethernet/cadence/macb.h | 74 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 105 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index c0fb80a..575022e 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2085,6 +2085,9 @@ static int macb_open(struct net_device *dev)
>
> netif_tx_start_all_queues(dev);
>
> + if (bp->ptp_info)
> + bp->ptp_info->ptp_init(dev);
> +
> return 0;
> }
>
> @@ -2106,6 +2109,9 @@ static int macb_close(struct net_device *dev)
>
> macb_free_consistent(bp);
>
> + if (bp->ptp_info)
> + bp->ptp_info->ptp_remove(dev);
> +
> return 0;
> }
>
> @@ -2379,6 +2385,17 @@ static int macb_set_ringparam(struct net_device *netdev,
> return 0;
> }
>
> +static int macb_get_ts_info(struct net_device *netdev,
> + struct ethtool_ts_info *info)
> +{
> + struct macb *bp = netdev_priv(netdev);
> +
> + if (bp->ptp_info)
> + return bp->ptp_info->get_ts_info(netdev, info);
> +
> + return ethtool_op_get_ts_info(netdev, info);
> +}
> +
> static const struct ethtool_ops macb_ethtool_ops = {
> .get_regs_len = macb_get_regs_len,
> .get_regs = macb_get_regs,
> @@ -2396,7 +2413,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
> .get_regs_len = macb_get_regs_len,
> .get_regs = macb_get_regs,
> .get_link = ethtool_op_get_link,
> - .get_ts_info = ethtool_op_get_ts_info,
> + .get_ts_info = macb_get_ts_info,
> .get_ethtool_stats = gem_get_ethtool_stats,
> .get_strings = gem_get_ethtool_strings,
> .get_sset_count = gem_get_sset_count,
> @@ -2409,6 +2426,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
> static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> {
> struct phy_device *phydev = dev->phydev;
> + struct macb *bp = netdev_priv(dev);
>
> if (!netif_running(dev))
> return -EINVAL;
> @@ -2416,7 +2434,17 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> if (!phydev)
> return -ENODEV;
>
> - return phy_mii_ioctl(phydev, rq, cmd);
> + if (!bp->ptp_info)
> + return phy_mii_ioctl(phydev, rq, cmd);
> +
> + switch (cmd) {
> + case SIOCSHWTSTAMP:
> + return bp->ptp_info->set_hwtst(dev, rq, cmd);
> + case SIOCGHWTSTAMP:
> + return bp->ptp_info->get_hwtst(dev, rq);
> + default:
> + return phy_mii_ioctl(phydev, rq, cmd);
> + }
> }
>
> static int macb_set_features(struct net_device *netdev,
> @@ -2490,6 +2518,7 @@ static void macb_configure_caps(struct macb *bp,
> dcfg = gem_readl(bp, DCFG2);
> if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF))) == 0)
> bp->caps |= MACB_CAPS_FIFO_MODE;
> +
Nitpicking, just because other issue exists: this white line doesn't
belong to the patch.
> }
>
> dev_dbg(&bp->pdev->dev, "Cadence caps 0x%08x\n", bp->caps);
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index d67adad..15f4a13 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -131,6 +131,20 @@
> #define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */
> #define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */
> #define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */
> +#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */
> +#define GEM_TSH 0x01c0 /* 1588 Timer Seconds High */
> +#define GEM_TSL 0x01d0 /* 1588 Timer Seconds Low */
> +#define GEM_TN 0x01d4 /* 1588 Timer Nanoseconds */
> +#define GEM_TA 0x01d8 /* 1588 Timer Adjust */
> +#define GEM_TI 0x01dc /* 1588 Timer Increment */
> +#define GEM_EFTSL 0x01e0 /* PTP Event Frame Tx Seconds Low */
> +#define GEM_EFTN 0x01e4 /* PTP Event Frame Tx Nanoseconds */
> +#define GEM_EFRSL 0x01e8 /* PTP Event Frame Rx Seconds Low */
> +#define GEM_EFRN 0x01ec /* PTP Event Frame Rx Nanoseconds */
> +#define GEM_PEFTSL 0x01f0 /* PTP Peer Event Frame Tx Secs Low */
> +#define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
> +#define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
> +#define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
> #define GEM_DCFG1 0x0280 /* Design Config 1 */
> #define GEM_DCFG2 0x0284 /* Design Config 2 */
> #define GEM_DCFG3 0x0288 /* Design Config 3 */
> @@ -174,6 +188,7 @@
> #define MACB_NCR_TPF_SIZE 1
> #define MACB_TZQ_OFFSET 12 /* Transmit zero quantum pause frame */
> #define MACB_TZQ_SIZE 1
> +#define MACB_SRTSM_OFFSET 15
>
> /* Bitfields in NCFGR */
> #define MACB_SPD_OFFSET 0 /* Speed */
> @@ -319,6 +334,32 @@
> #define MACB_PTZ_SIZE 1
> #define MACB_WOL_OFFSET 14 /* Enable wake-on-lan interrupt */
> #define MACB_WOL_SIZE 1
> +#define MACB_DRQFR_OFFSET 18 /* PTP Delay Request Frame Received */
> +#define MACB_DRQFR_SIZE 1
> +#define MACB_SFR_OFFSET 19 /* PTP Sync Frame Received */
> +#define MACB_SFR_SIZE 1
> +#define MACB_DRQFT_OFFSET 20 /* PTP Delay Request Frame Transmitted */
> +#define MACB_DRQFT_SIZE 1
> +#define MACB_SFT_OFFSET 21 /* PTP Sync Frame Transmitted */
> +#define MACB_SFT_SIZE 1
> +#define MACB_PDRQFR_OFFSET 22 /* PDelay Request Frame Received */
> +#define MACB_PDRQFR_SIZE 1
> +#define MACB_PDRSFR_OFFSET 23 /* PDelay Response Frame Received */
> +#define MACB_PDRSFR_SIZE 1
> +#define MACB_PDRQFT_OFFSET 24 /* PDelay Request Frame Transmitted */
> +#define MACB_PDRQFT_SIZE 1
> +#define MACB_PDRSFT_OFFSET 25 /* PDelay Response Frame Transmitted */
> +#define MACB_PDRSFT_SIZE 1
> +#define MACB_SRI_OFFSET 26 /* TSU Seconds Register Increment */
> +#define MACB_SRI_SIZE 1
> +
> +/* Timer increment fields */
> +#define MACB_TI_CNS_OFFSET 0
> +#define MACB_TI_CNS_SIZE 8
> +#define MACB_TI_ACNS_OFFSET 8
> +#define MACB_TI_ACNS_SIZE 8
> +#define MACB_TI_NIT_OFFSET 16
> +#define MACB_TI_NIT_SIZE 8
>
> /* Bitfields in MAN */
> #define MACB_DATA_OFFSET 0 /* data */
> @@ -386,6 +427,17 @@
> #define GEM_PBUF_LSO_OFFSET 27
> #define GEM_PBUF_LSO_SIZE 1
>
> +/* Bitfields in TISUBN */
> +#define GEM_SUBNSINCR_OFFSET 0
> +#define GEM_SUBNSINCR_SIZE 16
> +
> +/* Bitfields in TI */
> +#define GEM_NSINCR_OFFSET 0
> +#define GEM_NSINCR_SIZE 8
> +
> +/* Bitfields in ADJ */
> +#define GEM_ADDSUB_OFFSET 31
> +#define GEM_ADDSUB_SIZE 1
> /* Constants for CLK */
> #define MACB_CLK_DIV8 0
> #define MACB_CLK_DIV16 1
> @@ -417,6 +469,7 @@
> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
> #define MACB_CAPS_SG_DISABLED 0x40000000
> #define MACB_CAPS_MACB_IS_GEM 0x80000000
> +#define MACB_CAPS_GEM_HAS_PTP 0x00000020
No, this mask already exists a couple of lines above:
#define MACB_CAPS_JUMBO 0x00000020
That leads to a NACK, sorry (I didn't spotted earlier, BTW).
> /* LSO settings */
> #define MACB_LSO_UFO_ENABLE 0x01
> @@ -782,6 +835,20 @@ struct macb_or_gem_ops {
> int (*mog_rx)(struct macb *bp, int budget);
> };
>
> +/* MACB-PTP interface: adapt to platform needs. */
> +struct macb_ptp_info {
> + void (*ptp_init)(struct net_device *ndev);
> + void (*ptp_remove)(struct net_device *ndev);
> + s32 (*get_ptp_max_adj)(void);
> + unsigned int (*get_tsu_rate)(struct macb *bp);
> + int (*get_ts_info)(struct net_device *dev,
> + struct ethtool_ts_info *info);
> + int (*get_hwtst)(struct net_device *netdev,
> + struct ifreq *ifr);
> + int (*set_hwtst)(struct net_device *netdev,
> + struct ifreq *ifr, int cmd);
> +};
> +
> struct macb_config {
> u32 caps;
> unsigned int dma_burst_length;
> @@ -874,6 +941,8 @@ struct macb {
> unsigned int jumbo_max_len;
>
> u32 wol;
> +
> + struct macb_ptp_info *ptp_info; /* macb-ptp interface */
> };
>
> static inline bool macb_is_gem(struct macb *bp)
> @@ -881,4 +950,9 @@ static inline bool macb_is_gem(struct macb *bp)
> return !!(bp->caps & MACB_CAPS_MACB_IS_GEM);
> }
>
> +static inline bool gem_has_ptp(struct macb *bp)
> +{
> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
> +}
> +
> #endif /* _MACB_H */
Otherwise, I'm okay with the rest.
I suggest to people that will keep the ball rolling on this topic to
take advantage of the chunks of code that Andrei developed with the help
of Richard and the best practices discussed. I think particularly, if it
makes sense with HW, about:
- gem_ptp_do_[rt]xstamp(bp, skb) dereference scheme
- gem_ptp_adjfine() rationale
- gem_get_ptp_peer() if needed
Regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: David Miller @ 2017-01-18 17:32 UTC (permalink / raw)
To: saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
Cc: saeedm-VPRAkNaXOzVWk0Htik3J/w, dledford-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
leon-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <CALzJLG--ZRVk0Zy+6UaGCWbOhki+PZnkmrh9rjojU1ZDm_5Y6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Saeed Mahameed <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Date: Mon, 16 Jan 2017 22:30:29 +0200
>> But please bear with me here, what if we queue this patch up to -stable ?
You've got to be seriously kidding me that your idea is to submit an
incredibly diruptive driver rename to -stable to solve this problem.
That is completely a non-starter.
The whole idea is to _MINIMIZE_ the amount of change happening in
-stable in order to avoid regressions and negative consequence for
everyone using the -stable tree.
I am strongly against a major reorganization of this driver, sorry.
The Synopsys folks want to do the same thing for the stmmac driver,
for even more nefarious reasons, and I'm rejecting all of their
attempts to do that as well.
If you look in that thread, they said they would "help" with the
-stable backports, and in there I explained why that is a completely
empty gesture. There are people doing the backports outside of your
spehere of influence, who need to get their work done "right now" and
aren't going to consult you and be on your schedule for doing those
backports.
--
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: resend: tcp: performance issue with fastopen connections (mss > window)
From: Alexey Kodanev @ 2017-01-18 17:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Vasily Isaenko, Neal Cardwell,
Yuchung Cheng, Eric Dumazet
In-Reply-To: <22b07900-2151-a31f-34aa-7fb47c958423@oracle.com>
Hi Eric,
On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
> Hi Eric,
> On 13.01.2017 18:35, Eric Dumazet wrote:
>
>> I would suggest to clamp MSS to half the initial window, but I guess
>> this is impractical since window in SYN/SYNACK are not scaled.
Looks like max_window not correctly initialized for tfo sockets.
On my test machine it has set to '5592320' in tcp_fastopen_create_child().
This diff fixes the issue, the question: is this the right place to do it?
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 4e777a3..33ed508 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -206,6 +206,8 @@ static struct sock *tcp_fastopen_create_child(struct
sock *sk,
*/
tp->snd_wnd = ntohs(tcp_hdr(skb)->window);
+ tp->max_window = tp->snd_wnd;
+
/* Activate the retrans timer so that SYNACK can be retransmitted.
* The request socket is not added to the ehash
* because it's been added to the accept queue directly.
Thanks,
Alexey
^ permalink raw reply related
* Re: [PATCH v2 net-next] net:add one common config ARCH_WANT_RELAX_ORDER to support relax ordering.
From: Alexander Duyck @ 2017-01-18 17:25 UTC (permalink / raw)
To: David Laight
Cc: David Miller, maowenan@huawei.com, netdev@vger.kernel.org,
jeffrey.t.kirsher@intel.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0266CD6@AcuExch.aculab.com>
On Wed, Jan 18, 2017 at 8:22 AM, David Laight <David.Laight@aculab.com> wrote:
> From: David Miller
>> Sent: 17 January 2017 19:16
>> > Relax ordering(RO) is one feature of 82599 NIC, to enable this feature can
>> > enhance the performance for some cpu architecure, such as SPARC and so on.
>> > Currently it only supports one special cpu architecture(SPARC) in 82599
>> > driver to enable RO feature, this is not very common for other cpu architecture
>> > which really needs RO feature.
>> > This patch add one common config CONFIG_ARCH_WANT_RELAX_ORDER to set RO feature,
>> > and should define CONFIG_ARCH_WANT_RELAX_ORDER in sparc Kconfig firstly.
>> >
>> > Signed-off-by: Mao Wenan <maowenan@huawei.com>
>>
>> Since no-one has reviewed this patch, and I do not feel comfortable with applying
>> it without such review, I am tossing this patch.
>>
>> If someone eventually reviews it, repost this patch.
>
> Having re-read parts of the PCIe spec I think I'd like someone to
> explain exactly which transfers are affected by the 'relaxed ordering'
> bit and why any re-ordered transactions aren't a problem.
>
> In particular I believe RO allows the write to update the receive
> descriptor ring to overtake a write of receive packet data.
> That could lead to the network stack processing a receive frame
> before it has actually been written.
>
> David
>
The Relaxed Ordering attribute doesn't get applied across the board.
It ends up being limited to a subset of the transactions if I recall
correctly. In this case it is the Tx descriptor write back, and the
Rx data write back. We don't apply the RO bit to any other
transactions.
In the case of Tx descriptor there is no harm in allowing it to be
reordered because we only really read the DD bit so we don't care
about the ordering of the write back. In the case of the Rx data the
Rx descriptor essentially acts as a flush since it is sent without the
RO bit set. So all the writes before it must be completed before the
Rx descriptor write back.
- Alex
^ permalink raw reply
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Jason Gunthorpe @ 2017-01-18 16:46 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Vishwanathapura, Niranjana, ira.weiny, Doug Ledford, Jeff Kirsher,
David S. Miller, linux-rdma, netdev, dennis.dalessandro
In-Reply-To: <20170118054354.GT32481@mtr-leonro.local>
On Wed, Jan 18, 2017 at 07:43:54AM +0200, Leon Romanovsky wrote:
> > I have started working on porting hfi_vnic as per this new interface.
> > I will post RFC v3 later.
> > Posting the interface definition early for comments.
>
> I wonder how many people will comment it without seeing usage example.
It is my hope that Mellanox will contribute to this and use it for
ipoib - we've have had conversations along these lines in the
past... Apparently mlx4/5 could run quite a bit faster if used like
this.
Jason
^ permalink raw reply
* Re: [PATCH net-next] net: Remove usage of net_device last_rx member
From: Eric Dumazet @ 2017-01-18 17:23 UTC (permalink / raw)
To: Tobias Klauser
Cc: devel, netdev, b.a.t.m.a.n, linux-m68k, intel-wired-lan,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, Mirko Lindner
In-Reply-To: <20170118164501.1934-1-tklauser@distanz.ch>
On Wed, 2017-01-18 at 17:45 +0100, Tobias Klauser wrote:
> The network stack no longer uses the last_rx member of struct net_device
> since the bonding driver switched to use its own private last_rx in
> commit 9f242738376d ("bonding: use last_arp_rx in slave_last_rx()").
>
> However, some drivers still (ab)use the field for their own purposes and
> some driver just update it without actually using it.
>
> Previously, there was an accompanying comment for the last_rx member
> added in commit 4dc89133f49b ("net: add a comment on netdev->last_rx")
> which asked drivers not to update is, unless really needed. However,
> this commend was removed in commit f8ff080dacec ("bonding: remove
> useless updating of slave->dev->last_rx"), so some drivers added later
> on still did update last_rx.
>
> Remove all usage of last_rx and switch three drivers (sky2, atp and
> smc91c92_cs) which actually read and write it to use their own private
> copy in netdev_priv.
>
> Compile-tested with allyesconfig and allmodconfig on x86 and arm.
SGTM, thanks a lot for doing this Tobias.
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] ip/xfrm: Fix deleteall when having many policies installed
From: Stephen Hemminger @ 2017-01-18 17:03 UTC (permalink / raw)
To: Alexander Heinlein; +Cc: netdev, shemminger
In-Reply-To: <d056322e-7c23-7e19-3bdb-4afa5f04e409@secunet.com>
On Mon, 16 Jan 2017 15:09:01 +0100
Alexander Heinlein <alexander.heinlein@secunet.com> wrote:
> Fix "Policy buffer overflow" error when trying to use deleteall with
> many policies installed.
>
> Signed-off-by: Alexander Heinlein <alexander.heinlein@secunet.com>
> ---
> ip/xfrm_policy.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/ip/xfrm_policy.c b/ip/xfrm_policy.c
> index cc9c0f1..451b982 100644
> --- a/ip/xfrm_policy.c
> +++ b/ip/xfrm_policy.c
> @@ -732,10 +732,8 @@ static int xfrm_policy_keep(const struct
> sockaddr_nl *who,
Patch is not formatted properly because your mailer is line wrapping
^ permalink raw reply
* Re: [PATCH] stmicro: add more information to Kconfig
From: David Miller @ 2017-01-18 17:12 UTC (permalink / raw)
To: Joao.Pinto; +Cc: peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <8e4b7bbd48a0b2ff1374fdffe6d07dc00659e951.1484664500.git.jpinto@synopsys.com>
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Tue, 17 Jan 2017 14:53:07 +0000
> This patch adds more info to stmicro' Kconfig files in order to be clearer
> that the driver can be used by ethernet cards based on 10/100/1000/EQOS
> Synopsys IP Cores.
>
> EQOS was also added stmmac/Kconfig Kconfig, since dwmac4 is in fact EQoS,
> one of Synopsys Ethernet IPs. More info at:
> https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_qos
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next V5 2/3] vhost_net: tx batching
From: Michael S. Tsirkin @ 2017-01-18 17:03 UTC (permalink / raw)
To: Jason Wang; +Cc: virtualization, netdev, kvm, stephen, wexu, stefanha
In-Reply-To: <1484722923-7698-3-git-send-email-jasowang@redhat.com>
On Wed, Jan 18, 2017 at 03:02:02PM +0800, Jason Wang wrote:
> This patch tries to utilize tuntap rx batching by peeking the tx
> virtqueue during transmission, if there's more available buffers in
> the virtqueue, set MSG_MORE flag for a hint for backend (e.g tuntap)
> to batch the packets.
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/net.c | 23 ++++++++++++++++++++---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 5dc3465..c42e9c3 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -351,6 +351,15 @@ static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
> return r;
> }
>
> +static bool vhost_exceeds_maxpend(struct vhost_net *net)
> +{
> + struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
> + struct vhost_virtqueue *vq = &nvq->vq;
> +
> + return (nvq->upend_idx + vq->num - VHOST_MAX_PEND) % UIO_MAXIOV
> + == nvq->done_idx;
> +}
> +
> /* Expects to be always run from workqueue - which acts as
> * read-size critical section for our kind of RCU. */
> static void handle_tx(struct vhost_net *net)
> @@ -394,8 +403,7 @@ static void handle_tx(struct vhost_net *net)
> /* If more outstanding DMAs, queue the work.
> * Handle upend_idx wrap around
> */
> - if (unlikely((nvq->upend_idx + vq->num - VHOST_MAX_PEND)
> - % UIO_MAXIOV == nvq->done_idx))
> + if (unlikely(vhost_exceeds_maxpend(net)))
> break;
>
> head = vhost_net_tx_get_vq_desc(net, vq, vq->iov,
> @@ -454,6 +462,16 @@ static void handle_tx(struct vhost_net *net)
> msg.msg_control = NULL;
> ubufs = NULL;
> }
> +
> + total_len += len;
> + if (total_len < VHOST_NET_WEIGHT &&
> + !vhost_vq_avail_empty(&net->dev, vq) &&
> + likely(!vhost_exceeds_maxpend(net))) {
> + msg.msg_flags |= MSG_MORE;
> + } else {
> + msg.msg_flags &= ~MSG_MORE;
> + }
> +
> /* TODO: Check specific error and bomb out unless ENOBUFS? */
> err = sock->ops->sendmsg(sock, &msg, len);
> if (unlikely(err < 0)) {
> @@ -472,7 +490,6 @@ static void handle_tx(struct vhost_net *net)
> vhost_add_used_and_signal(&net->dev, vq, head, 0);
> else
> vhost_zerocopy_signal_used(net, vq);
> - total_len += len;
> vhost_net_tx_packet(net);
> if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
> vhost_poll_queue(&vq->poll);
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH net-next V5 3/3] tun: rx batching
From: Michael S. Tsirkin @ 2017-01-18 17:03 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, netdev, virtualization, wexu, stefanha
In-Reply-To: <1484722923-7698-4-git-send-email-jasowang@redhat.com>
On Wed, Jan 18, 2017 at 03:02:03PM +0800, Jason Wang wrote:
> We can only process 1 packet at one time during sendmsg(). This often
> lead bad cache utilization under heavy load. So this patch tries to do
> some batching during rx before submitting them to host network
> stack. This is done through accepting MSG_MORE as a hint from
> sendmsg() caller, if it was set, batch the packet temporarily in a
> linked list and submit them all once MSG_MORE were cleared.
>
> Tests were done by pktgen (burst=128) in guest over mlx4(noqueue) on host:
>
> Mpps -+%
> rx-frames = 0 0.91 +0%
> rx-frames = 4 1.00 +9.8%
> rx-frames = 8 1.00 +9.8%
> rx-frames = 16 1.01 +10.9%
> rx-frames = 32 1.07 +17.5%
> rx-frames = 48 1.07 +17.5%
> rx-frames = 64 1.08 +18.6%
> rx-frames = 64 (no MSG_MORE) 0.91 +0%
>
> User were allowed to change per device batched packets through
> ethtool -C rx-frames. NAPI_POLL_WEIGHT were used as upper limitation
> to prevent bh from being disabled too long.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/tun.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 8c1d3bd..13890ac 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -218,6 +218,7 @@ struct tun_struct {
> struct list_head disabled;
> void *security;
> u32 flow_count;
> + u32 rx_batched;
> struct tun_pcpu_stats __percpu *pcpu_stats;
> };
>
> @@ -522,6 +523,7 @@ static void tun_queue_purge(struct tun_file *tfile)
> while ((skb = skb_array_consume(&tfile->tx_array)) != NULL)
> kfree_skb(skb);
>
> + skb_queue_purge(&tfile->sk.sk_write_queue);
> skb_queue_purge(&tfile->sk.sk_error_queue);
> }
>
> @@ -1139,10 +1141,46 @@ static struct sk_buff *tun_alloc_skb(struct tun_file *tfile,
> return skb;
> }
>
> +static void tun_rx_batched(struct tun_struct *tun, struct tun_file *tfile,
> + struct sk_buff *skb, int more)
> +{
> + struct sk_buff_head *queue = &tfile->sk.sk_write_queue;
> + struct sk_buff_head process_queue;
> + u32 rx_batched = tun->rx_batched;
> + bool rcv = false;
> +
> + if (!rx_batched || (!more && skb_queue_empty(queue))) {
> + local_bh_disable();
> + netif_receive_skb(skb);
> + local_bh_enable();
> + return;
> + }
> +
> + spin_lock(&queue->lock);
> + if (!more || skb_queue_len(queue) == rx_batched) {
> + __skb_queue_head_init(&process_queue);
> + skb_queue_splice_tail_init(queue, &process_queue);
> + rcv = true;
> + } else {
> + __skb_queue_tail(queue, skb);
> + }
> + spin_unlock(&queue->lock);
> +
> + if (rcv) {
> + struct sk_buff *nskb;
> +
> + local_bh_disable();
> + while ((nskb = __skb_dequeue(&process_queue)))
> + netif_receive_skb(nskb);
> + netif_receive_skb(skb);
> + local_bh_enable();
> + }
> +}
> +
> /* Get packet from user space buffer */
> static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> void *msg_control, struct iov_iter *from,
> - int noblock)
> + int noblock, bool more)
> {
> struct tun_pi pi = { 0, cpu_to_be16(ETH_P_IP) };
> struct sk_buff *skb;
> @@ -1283,9 +1321,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
>
> rxhash = skb_get_hash(skb);
> #ifndef CONFIG_4KSTACKS
> - local_bh_disable();
> - netif_receive_skb(skb);
> - local_bh_enable();
> + tun_rx_batched(tun, tfile, skb, more);
> #else
> netif_rx_ni(skb);
> #endif
> @@ -1311,7 +1347,8 @@ static ssize_t tun_chr_write_iter(struct kiocb *iocb, struct iov_iter *from)
> if (!tun)
> return -EBADFD;
>
> - result = tun_get_user(tun, tfile, NULL, from, file->f_flags & O_NONBLOCK);
> + result = tun_get_user(tun, tfile, NULL, from,
> + file->f_flags & O_NONBLOCK, false);
>
> tun_put(tun);
> return result;
> @@ -1569,7 +1606,8 @@ static int tun_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len)
> return -EBADFD;
>
> ret = tun_get_user(tun, tfile, m->msg_control, &m->msg_iter,
> - m->msg_flags & MSG_DONTWAIT);
> + m->msg_flags & MSG_DONTWAIT,
> + m->msg_flags & MSG_MORE);
> tun_put(tun);
> return ret;
> }
> @@ -1770,6 +1808,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> tun->align = NET_SKB_PAD;
> tun->filter_attached = false;
> tun->sndbuf = tfile->socket.sk->sk_sndbuf;
> + tun->rx_batched = 0;
>
> tun->pcpu_stats = netdev_alloc_pcpu_stats(struct tun_pcpu_stats);
> if (!tun->pcpu_stats) {
> @@ -2438,6 +2477,29 @@ static void tun_set_msglevel(struct net_device *dev, u32 value)
> #endif
> }
>
> +static int tun_get_coalesce(struct net_device *dev,
> + struct ethtool_coalesce *ec)
> +{
> + struct tun_struct *tun = netdev_priv(dev);
> +
> + ec->rx_max_coalesced_frames = tun->rx_batched;
> +
> + return 0;
> +}
> +
> +static int tun_set_coalesce(struct net_device *dev,
> + struct ethtool_coalesce *ec)
> +{
> + struct tun_struct *tun = netdev_priv(dev);
> +
> + if (ec->rx_max_coalesced_frames > NAPI_POLL_WEIGHT)
> + tun->rx_batched = NAPI_POLL_WEIGHT;
> + else
> + tun->rx_batched = ec->rx_max_coalesced_frames;
> +
> + return 0;
> +}
> +
> static const struct ethtool_ops tun_ethtool_ops = {
> .get_settings = tun_get_settings,
> .get_drvinfo = tun_get_drvinfo,
> @@ -2445,6 +2507,8 @@ static const struct ethtool_ops tun_ethtool_ops = {
> .set_msglevel = tun_set_msglevel,
> .get_link = ethtool_op_get_link,
> .get_ts_info = ethtool_op_get_ts_info,
> + .get_coalesce = tun_get_coalesce,
> + .set_coalesce = tun_set_coalesce,
> };
>
> static int tun_queue_resize(struct tun_struct *tun)
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH net-next V5 1/3] vhost: better detection of available buffers
From: Michael S. Tsirkin @ 2017-01-18 17:03 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, netdev, virtualization, wexu, stefanha
In-Reply-To: <1484722923-7698-2-git-send-email-jasowang@redhat.com>
On Wed, Jan 18, 2017 at 03:02:01PM +0800, Jason Wang wrote:
> This patch tries to do several tweaks on vhost_vq_avail_empty() for a
> better performance:
>
> - check cached avail index first which could avoid userspace memory access.
> - using unlikely() for the failure of userspace access
> - check vq->last_avail_idx instead of cached avail index as the last
> step.
>
> This patch is need for batching supports which needs to peek whether
> or not there's still available buffers in the ring.
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/vhost.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index d643260..9f11838 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2241,11 +2241,15 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> __virtio16 avail_idx;
> int r;
>
> + if (vq->avail_idx != vq->last_avail_idx)
> + return false;
> +
> r = vhost_get_user(vq, avail_idx, &vq->avail->idx);
> - if (r)
> + if (unlikely(r))
> return false;
> + vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
>
> - return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx;
> + return vq->avail_idx == vq->last_avail_idx;
> }
> EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
From: Vineeth Remanan Pillai @ 2017-01-18 17:02 UTC (permalink / raw)
To: Juergen Gross, David Miller, boris.ostrovsky, xen-devel, netdev,
linux-kernel
Cc: kamatam, vineethp, aliguori
In-Reply-To: <ee87b2e4-de8c-7b9b-c4e5-854ffab2e554@suse.com>
On 01/15/2017 10:24 PM, Juergen Gross wrote:
> On 13/01/17 18:55, Remanan Pillai wrote:
>> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>>
>> During an OOM scenario, request slots could not be created as skb
>> allocation fails. So the netback cannot pass in packets and netfront
>> wrongly assumes that there is no more work to be done and it disables
>> polling. This causes Rx to stall.
>>
>> The issue is with the retry logic which schedules the timer if the
>> created slots are less than NET_RX_SLOTS_MIN. The count of new request
>> slots to be pushed are calculated as a difference between new req_prod
>> and rsp_cons which could be more than the actual slots, if there are
>> unconsumed responses.
>>
>> The fix is to calculate the count of newly created slots as the
>> difference between new req_prod and old req_prod.
>>
>> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
Thanks Juergen.
David,
Could you please pick up this change for net-next if there no more
concerns..
Many Thanks,
Vineeth
>
>
> Thanks,
>
> Juergen
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH net-next] macb: Common code to enable ptp support for SAMA5Dx platforms.
From: Andrei Pistirica @ 2017-01-18 16:57 UTC (permalink / raw)
To: netdev, linux-kernel, linux-arm-kernel, davem, nicolas.ferre,
harinikatakamlinux, harini.katakam
Cc: boris.brezillon, rafalo, alexandre.belloni, michals,
Andrei Pistirica, tbultel, anirudh, punnaia, richardcochran
This patch does the following:
- add GEM-PTP interface
- registers and bitfields for TSU are named according to SAMA5Dx data sheet
- PTP support based on platform capability
Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
---
This is just the common code for GEM-PTP support. Code is based on the comments
related to the following patch series:
- [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM.
- [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx platforms.
Note: Patch on net-next: January 18.
Rafal/Harini, you can continue the work for GME-GXL.
drivers/net/ethernet/cadence/macb.c | 33 ++++++++++++++++-
drivers/net/ethernet/cadence/macb.h | 74 +++++++++++++++++++++++++++++++++++++
2 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index c0fb80a..575022e 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2085,6 +2085,9 @@ static int macb_open(struct net_device *dev)
netif_tx_start_all_queues(dev);
+ if (bp->ptp_info)
+ bp->ptp_info->ptp_init(dev);
+
return 0;
}
@@ -2106,6 +2109,9 @@ static int macb_close(struct net_device *dev)
macb_free_consistent(bp);
+ if (bp->ptp_info)
+ bp->ptp_info->ptp_remove(dev);
+
return 0;
}
@@ -2379,6 +2385,17 @@ static int macb_set_ringparam(struct net_device *netdev,
return 0;
}
+static int macb_get_ts_info(struct net_device *netdev,
+ struct ethtool_ts_info *info)
+{
+ struct macb *bp = netdev_priv(netdev);
+
+ if (bp->ptp_info)
+ return bp->ptp_info->get_ts_info(netdev, info);
+
+ return ethtool_op_get_ts_info(netdev, info);
+}
+
static const struct ethtool_ops macb_ethtool_ops = {
.get_regs_len = macb_get_regs_len,
.get_regs = macb_get_regs,
@@ -2396,7 +2413,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
.get_regs_len = macb_get_regs_len,
.get_regs = macb_get_regs,
.get_link = ethtool_op_get_link,
- .get_ts_info = ethtool_op_get_ts_info,
+ .get_ts_info = macb_get_ts_info,
.get_ethtool_stats = gem_get_ethtool_stats,
.get_strings = gem_get_ethtool_strings,
.get_sset_count = gem_get_sset_count,
@@ -2409,6 +2426,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct phy_device *phydev = dev->phydev;
+ struct macb *bp = netdev_priv(dev);
if (!netif_running(dev))
return -EINVAL;
@@ -2416,7 +2434,17 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
if (!phydev)
return -ENODEV;
- return phy_mii_ioctl(phydev, rq, cmd);
+ if (!bp->ptp_info)
+ return phy_mii_ioctl(phydev, rq, cmd);
+
+ switch (cmd) {
+ case SIOCSHWTSTAMP:
+ return bp->ptp_info->set_hwtst(dev, rq, cmd);
+ case SIOCGHWTSTAMP:
+ return bp->ptp_info->get_hwtst(dev, rq);
+ default:
+ return phy_mii_ioctl(phydev, rq, cmd);
+ }
}
static int macb_set_features(struct net_device *netdev,
@@ -2490,6 +2518,7 @@ static void macb_configure_caps(struct macb *bp,
dcfg = gem_readl(bp, DCFG2);
if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF))) == 0)
bp->caps |= MACB_CAPS_FIFO_MODE;
+
}
dev_dbg(&bp->pdev->dev, "Cadence caps 0x%08x\n", bp->caps);
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index d67adad..15f4a13 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -131,6 +131,20 @@
#define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */
#define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */
#define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */
+#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */
+#define GEM_TSH 0x01c0 /* 1588 Timer Seconds High */
+#define GEM_TSL 0x01d0 /* 1588 Timer Seconds Low */
+#define GEM_TN 0x01d4 /* 1588 Timer Nanoseconds */
+#define GEM_TA 0x01d8 /* 1588 Timer Adjust */
+#define GEM_TI 0x01dc /* 1588 Timer Increment */
+#define GEM_EFTSL 0x01e0 /* PTP Event Frame Tx Seconds Low */
+#define GEM_EFTN 0x01e4 /* PTP Event Frame Tx Nanoseconds */
+#define GEM_EFRSL 0x01e8 /* PTP Event Frame Rx Seconds Low */
+#define GEM_EFRN 0x01ec /* PTP Event Frame Rx Nanoseconds */
+#define GEM_PEFTSL 0x01f0 /* PTP Peer Event Frame Tx Secs Low */
+#define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
+#define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
+#define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
#define GEM_DCFG1 0x0280 /* Design Config 1 */
#define GEM_DCFG2 0x0284 /* Design Config 2 */
#define GEM_DCFG3 0x0288 /* Design Config 3 */
@@ -174,6 +188,7 @@
#define MACB_NCR_TPF_SIZE 1
#define MACB_TZQ_OFFSET 12 /* Transmit zero quantum pause frame */
#define MACB_TZQ_SIZE 1
+#define MACB_SRTSM_OFFSET 15
/* Bitfields in NCFGR */
#define MACB_SPD_OFFSET 0 /* Speed */
@@ -319,6 +334,32 @@
#define MACB_PTZ_SIZE 1
#define MACB_WOL_OFFSET 14 /* Enable wake-on-lan interrupt */
#define MACB_WOL_SIZE 1
+#define MACB_DRQFR_OFFSET 18 /* PTP Delay Request Frame Received */
+#define MACB_DRQFR_SIZE 1
+#define MACB_SFR_OFFSET 19 /* PTP Sync Frame Received */
+#define MACB_SFR_SIZE 1
+#define MACB_DRQFT_OFFSET 20 /* PTP Delay Request Frame Transmitted */
+#define MACB_DRQFT_SIZE 1
+#define MACB_SFT_OFFSET 21 /* PTP Sync Frame Transmitted */
+#define MACB_SFT_SIZE 1
+#define MACB_PDRQFR_OFFSET 22 /* PDelay Request Frame Received */
+#define MACB_PDRQFR_SIZE 1
+#define MACB_PDRSFR_OFFSET 23 /* PDelay Response Frame Received */
+#define MACB_PDRSFR_SIZE 1
+#define MACB_PDRQFT_OFFSET 24 /* PDelay Request Frame Transmitted */
+#define MACB_PDRQFT_SIZE 1
+#define MACB_PDRSFT_OFFSET 25 /* PDelay Response Frame Transmitted */
+#define MACB_PDRSFT_SIZE 1
+#define MACB_SRI_OFFSET 26 /* TSU Seconds Register Increment */
+#define MACB_SRI_SIZE 1
+
+/* Timer increment fields */
+#define MACB_TI_CNS_OFFSET 0
+#define MACB_TI_CNS_SIZE 8
+#define MACB_TI_ACNS_OFFSET 8
+#define MACB_TI_ACNS_SIZE 8
+#define MACB_TI_NIT_OFFSET 16
+#define MACB_TI_NIT_SIZE 8
/* Bitfields in MAN */
#define MACB_DATA_OFFSET 0 /* data */
@@ -386,6 +427,17 @@
#define GEM_PBUF_LSO_OFFSET 27
#define GEM_PBUF_LSO_SIZE 1
+/* Bitfields in TISUBN */
+#define GEM_SUBNSINCR_OFFSET 0
+#define GEM_SUBNSINCR_SIZE 16
+
+/* Bitfields in TI */
+#define GEM_NSINCR_OFFSET 0
+#define GEM_NSINCR_SIZE 8
+
+/* Bitfields in ADJ */
+#define GEM_ADDSUB_OFFSET 31
+#define GEM_ADDSUB_SIZE 1
/* Constants for CLK */
#define MACB_CLK_DIV8 0
#define MACB_CLK_DIV16 1
@@ -417,6 +469,7 @@
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
#define MACB_CAPS_SG_DISABLED 0x40000000
#define MACB_CAPS_MACB_IS_GEM 0x80000000
+#define MACB_CAPS_GEM_HAS_PTP 0x00000020
/* LSO settings */
#define MACB_LSO_UFO_ENABLE 0x01
@@ -782,6 +835,20 @@ struct macb_or_gem_ops {
int (*mog_rx)(struct macb *bp, int budget);
};
+/* MACB-PTP interface: adapt to platform needs. */
+struct macb_ptp_info {
+ void (*ptp_init)(struct net_device *ndev);
+ void (*ptp_remove)(struct net_device *ndev);
+ s32 (*get_ptp_max_adj)(void);
+ unsigned int (*get_tsu_rate)(struct macb *bp);
+ int (*get_ts_info)(struct net_device *dev,
+ struct ethtool_ts_info *info);
+ int (*get_hwtst)(struct net_device *netdev,
+ struct ifreq *ifr);
+ int (*set_hwtst)(struct net_device *netdev,
+ struct ifreq *ifr, int cmd);
+};
+
struct macb_config {
u32 caps;
unsigned int dma_burst_length;
@@ -874,6 +941,8 @@ struct macb {
unsigned int jumbo_max_len;
u32 wol;
+
+ struct macb_ptp_info *ptp_info; /* macb-ptp interface */
};
static inline bool macb_is_gem(struct macb *bp)
@@ -881,4 +950,9 @@ static inline bool macb_is_gem(struct macb *bp)
return !!(bp->caps & MACB_CAPS_MACB_IS_GEM);
}
+static inline bool gem_has_ptp(struct macb *bp)
+{
+ return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
+}
+
#endif /* _MACB_H */
--
2.7.4
^ permalink raw reply related
* Re: [RFC] RESEND - rdmatool - tool for RDMA users
From: Or Gerlitz @ 2017-01-18 16:48 UTC (permalink / raw)
To: Ariel Almog
Cc: Leon Romanovsky,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Netdev List
In-Reply-To: <CABvr3-GZQs51Sn3XagTsepsy3CHvx6P=GVJzefajbNt9jxz9Kg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 18, 2017 at 5:19 PM, Ariel Almog
<arielalmogworkemails-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> General
> *******
> As of today, there is no single, simple, tool that allows monitoring
> and configuration of RDMA stack.
Before tool, what kernel UAPI you thought to use?
> rdmatool will provide standard, provider agnostic, user interface.
> RDMA user can use this interface to
> * Query RDMA device capabilities
> * Query RDMA device status and current open resources
> * Fetching RDMA statistics
> * Configure RDMA device
>
> The rdmatool will have the ability to control RDMA stack which
> includes the ib_device and RDMA protocol params.
>
> It is a good point to highlight the similarity to ethtool. It manages
> net_device, while rdmatool will manage RDMA stack.
>
> As a proposal, it is appealing to have a similar design to ethtool for
> rdmatool too. As ethtool, it should contain user space part, kernel
> handler and vendor specific handler(s).
>
> Another tool which allows similar functionality is iproute2. Iproute2
> allows user space tools to configure and query transport, network and
> link layer. The advantages of using iproute2 is the reuse of existing
> tool and familiar interface in addition to the wide spreading of this tool.
>
> As start point of the discussion, we would like to propose two
> implementation options for the rdmatool:
> (1) Build a tool using ABI interface. This will be a RDMA tool
> which will be distributed as part of RDMA package
> (2) Enhancing iproute2 to include rdmatool functionality
>
> Our opinion is that the new ABI interface provides vast functionality and
> it will be a waste to use other interface for the same functionality.
> Each of the proposed implementation above have their advantages, and we
> would like to hear your opinion regarding this direction.
> I’m posting this RFC in both netdev and linux-rdma communities in
> order to get feedback on this topic.
What's wrong with the RDMA netlink infrastructure?! it's there for
years and used
for various cases by MLNX, did you look on the code?
cea05ea IB/core: Add flow control to the portmapper netlink calls
ae43f82 IB/core: Add IP to GID netlink offload
2ca546b IB/sa: Route SA pathrecord query through netlink
753f618 RDMA/cma: Add support for netlink statistics export
b2cbae2 RDMA: Add netlink infrastructure
--
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: ethtool: avoid allocation failure for dump_regs
From: David Miller @ 2017-01-18 16:45 UTC (permalink / raw)
To: darcari; +Cc: netdev
In-Reply-To: <1484746445-97920-1-git-send-email-darcari@redhat.com>
From: David Arcari <darcari@redhat.com>
Date: Wed, 18 Jan 2017 08:34:05 -0500
> If the user executes 'ethtool -d' for an interface and the associated
> get_regs_len() function returns 0, the user will see a call trace from
> the vmalloc() call in ethtool_get_regs(). This patch modifies
> ethtool_get_regs() to avoid the call to vmalloc when the size is zero.
>
> Signed-off-by: David Arcari <darcari@redhat.com>
I think when the driver indicates this, it is equivalent to saying that
the operation isn't supported.
Also, this guards us against ->get_regs() methods that don't handle
zero length requests properly. I see many which are going to do
really terrible things in that situation.
Therefore, if get_regs_len() returns zero, treat it the safe as if the
ethtool operations were NULL.
Thanks.
^ 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