* [PATCH 0/2] sh_eth: massage PM code
From: Sergei Shtylyov @ 2015-01-21 22:16 UTC (permalink / raw)
To: netdev; +Cc: linux-sh
Hello.
Here's a set of 2 patches against DaveM's 'net-next.git' repo. We're adding
the support for suspend/hibernation as well as somewhat changing the existing
code. There are still MDIO-related issue with suspend (kernel exception), we've
been working on it and shall address it with a separate patch...
[1/2] sh_eth: use SET_RUNTIME_PM_OPS()
[2/2] sh_eth: add more PM methods
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Jesse Gross @ 2015-01-21 22:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx9B5aS9Jv6tpUJpmBkvQFnUqjcxcgTjbBHee8K0f1C9KQ@mail.gmail.com>
On Wed, Jan 21, 2015 at 1:54 PM, Tom Herbert <therbert@google.com> wrote:
> On Wed, Jan 21, 2015 at 12:35 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Wed, Jan 21, 2015 at 11:45 AM, Tom Herbert <therbert@google.com> wrote:
>>>> I used bare metal intel servers. All VXLAN tests were done using linux
>>>> kernel device without any VMs. All STT tests are done using OVS bridge
>>>> and STT port.
>>>>
>>> So right off the bat you're running the baseline differently than the
>>> target. Anyway, I cannot replicate your numbers for VXLAN, I see much
>>> better performance and this with pretty old servers and dumb NICs. I
>>> suspect you might not have GSO/GRO properly enabled, but instead of
>>> trying to debug your setup, I'd rather restate my request that you
>>> provide a network interface to STT so we can do our own fair
>>> comparison.
>>
>> If I had to guess, I suspect the difference is that UDP RSS wasn't
>> enabled, since it doesn't come that way out of the box. Regardless,
>> you can clearly see a significant difference in single core
>> performance and CPU consumption.
>>
> I'm not going to try to draw conclusions from data which is obviously
> biased and incomplete. If you want to move forward on this, then just
> provide network interface for STT so we can independently run our own
> comparisons against other encapsulations like we've been doing all
> along.
You have the source code, so you are totally free to run whatever
tests you like to draw your own conclusions. Personally, I find a more
than doubling of performance in the environments that I have seen
compelling. Your mileage may vary.
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-01-21 21:54 UTC (permalink / raw)
To: Jesse Gross; +Cc: Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <CAEP_g=-3GXJfawPb4jevkZhqmzTttsO1Rv_2J6GwpG=PR_a-0g@mail.gmail.com>
On Wed, Jan 21, 2015 at 12:35 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Wed, Jan 21, 2015 at 11:45 AM, Tom Herbert <therbert@google.com> wrote:
>>> I used bare metal intel servers. All VXLAN tests were done using linux
>>> kernel device without any VMs. All STT tests are done using OVS bridge
>>> and STT port.
>>>
>> So right off the bat you're running the baseline differently than the
>> target. Anyway, I cannot replicate your numbers for VXLAN, I see much
>> better performance and this with pretty old servers and dumb NICs. I
>> suspect you might not have GSO/GRO properly enabled, but instead of
>> trying to debug your setup, I'd rather restate my request that you
>> provide a network interface to STT so we can do our own fair
>> comparison.
>
> If I had to guess, I suspect the difference is that UDP RSS wasn't
> enabled, since it doesn't come that way out of the box. Regardless,
> you can clearly see a significant difference in single core
> performance and CPU consumption.
>
I'm not going to try to draw conclusions from data which is obviously
biased and incomplete. If you want to move forward on this, then just
provide network interface for STT so we can independently run our own
comparisons against other encapsulations like we've been doing all
along.
> STT has been fairly well known in network virtualization circles for
> the past few years and has some large deployments, so the reported
> performance is not a fluke. I remember Pankaj from Microsoft also
> mentioning to you that they weren't able to get performance to
> reasonable level without TSO. Totally different environment obviously
> but same reasoning.
>
>>>>> VXLAN:
>>>>> CPU
>>>>> Client: 1.6
>>>>> Server: 14.2
>>>>> Throughput: 5.6 Gbit/s
>>>>>
>>>>> VXLAN with rcsum:
>>>>> CPU
>>>>> Client: 0.89
>>>>> Server: 12.4
>>>>> Throughput: 5.8 Gbit/s
>>>>>
>>>>> STT:
>>>>> CPU
>>>>> Client: 1.28
>>>>> Server: 4.0
>>>>> Throughput: 9.5 Gbit/s
>>>>>
>>>> 9.5Gbps? Rounding error or is this 40Gbps or larger than 1500 byte MTU?
>>>>
>>> Nope, its same as VXLAN setup, 10Gbps NIC with 1500MTU.
>>>
>> That would exceed that theoretical maximum for TCP over 10Gbps
>> Ethernet. How are you measuring throughput? How many bytes of protocol
>> headers are in STT case?
>
> For large packet cases, STT actually has less header overhead compared
> to the unencapsulated traffic stream. This is because for a group of
> STT packets generated by a TSO burst from the guest there is only a
> single copy of the inner header. Even though TCP headers are used for
> encapsulation, there are no options - as opposed to the inner headers,
> which typically contain timestamps. Over the course of the ~45 packets
> that could be generated from a maximum sized transmission, this
> results in negative encapsulation overhead.
>
> I would recommend you take a look at the draft if you haven't already:
> http://tools.ietf.org/html/draft-davie-stt-06
>
> It is currently in the final stages of the RFC publication process.
^ permalink raw reply
* [PATCH] can: c_can: end pending transmission on network stop (ifdown)
From: Marc Kleine-Budde @ 2015-01-21 21:46 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Viktor Babrian, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1421876791-31014-1-git-send-email-mkl@pengutronix.de>
From: Viktor Babrian <babrian.viktor@renyi.mta.hu>
Put controller into init mode in network stop to end pending transmissions. The
issue is observed in cases when transmitted frame is not acked.
Signed-off-by: Viktor Babrian <babrian.viktor@renyi.mta.hu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index f94a9fa60488..c672c4dcffac 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -615,6 +615,9 @@ static void c_can_stop(struct net_device *dev)
c_can_irq_control(priv, false);
+ /* put ctrl to init on stop to end ongoing transmission */
+ priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_INIT);
+
/* deactivate pins */
pinctrl_pm_select_sleep_state(dev->dev.parent);
priv->can.state = CAN_STATE_STOPPED;
--
2.1.4
^ permalink raw reply related
* pull-request: can 2015-01-21
From: Marc Kleine-Budde @ 2015-01-21 21:46 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request for v3.19, net/master, which consists of a single patch.
Viktor Babrian fixes the issue in the c_can dirver, that the CAN interface
might continue to send frames after the interface has been shut down.
regards,
Marc
---
The following changes since commit 06efe0e54018cb19cf0807447dc3ac747ffcfd1c:
Merge tag 'pinctrl-v3.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl (2015-01-20 21:23:41 +1200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-3.19-20150121
for you to fetch changes up to 7ffd7b4e169d619e66928fe5d997723f2c6f1056:
can: c_can: end pending transmission on network stop (ifdown) (2015-01-21 22:43:14 +0100)
----------------------------------------------------------------
linux-can-fixes-for-3.19-20150121
----------------------------------------------------------------
Viktor Babrian (1):
can: c_can: end pending transmission on network stop (ifdown)
drivers/net/can/c_can/c_can.c | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply
* Re: [PATCH net v2] ipv4: try to cache dst_entries which would cause a redirect
From: Julian Anastasov @ 2015-01-21 21:26 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, Marcelo Leitner, Florian Westphal
In-Reply-To: <c758eb2d861f2eeb981615c3297b19443d4061d6.1421837207.git.hannes@stressinduktion.org>
Hello,
On Wed, 21 Jan 2015, Hannes Frederic Sowa wrote:
> Not caching dst_entries which cause redirects could be exploited by hosts
> on the same subnet, causing a severe DoS attack. This effect aggravated
> since commit f88649721268999 ("ipv4: fix dst race in sk_dst_get()").
>
> Lookups causing redirects will be allocated with DST_NOCACHE set which
> will force dst_release to free them via RCU. Unfortunately waiting for
> RCU grace period just takes too long, we can end up with >1M dst_entries
> waiting to be released and the system will run OOM. rcuos threads cannot
> catch up under high softirq load.
>
> Attaching the flag to emit a redirect later on to the specific skb allows
> us to cache those dst_entries thus reducing the pressure on allocation
> and deallocation.
>
> This issue was discovered by Marcelo Leitner.
After more thinking and after checking all
ip_route_input places other issues popup :(
Another place with non-trivial handling is
icmp_route_lookup(), only called by icmp_send(). We do
lookup and then revert it. ip_options_rcv_srr() too.
In this case we even can replace initial route (which
should be to local host, without redirect flag) with
new route (which can be with IPSKB_DOREDIRECT).
So, for this case we do not wrongly leave some
IPSKB_DOREDIRECT flag.
But in icmp_route_lookup() should we restore the
original IPSKB_DOREDIRECT bit when_skb_refdst is restored?
I.e. I'm not sure if some icmp_send() caller continues to
use the skb. For now I see only one place where we continue
to use skb after icmp_send: ip_rt_send_redirect(). But
it is after our check for RTCF_DOREDIRECT. Other places
free the skb.
If we want to be pedantic, should we create some
helper functions and structure to save old state? For now
we are ok but using IPCB looks risky. For example:
struct ip_route_input_state {
unsigned long refdst;
unsigned char flags;
};
/* Save state and re-init skb for new route lookup */
static inline void
ip_route_input_state_save(struct sk_buff *skb,
struct ip_route_input_state *state)
{
state->refdst = skb->_skb_refdst;
state->flags = IPCB(skb)->flags;
skb_dst_set(skb, NULL);
IPCB(skb)->flags &= ~IPSKB_DOREDIRECT;
}
static inline void
ip_route_input_state_restore(struct sk_buff *skb,
struct ip_route_input_state *state)
{
skb->_skb_refdst = state->refdst;
IPCB(skb)->flags = state->flags;
}
static inline void
ip_route_input_state_drop(struct ip_route_input_state *state)
{
refdst_drop(state->refdst);
}
> skb->priority = rt_tos2priority(iph->tos);
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 2000110..868c829 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1568,10 +1568,8 @@ static int __mkroute_input(struct sk_buff *skb,
> do_cache = res->fi && !itag;
> if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) &&
> (IN_DEV_SHARED_MEDIA(out_dev) ||
> - inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) {
> - flags |= RTCF_DOREDIRECT;
> - do_cache = false;
> - }
> + inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res))))
> + IPCB(skb)->flags |= IPSKB_DOREDIRECT;
Looks like accessing IPCB may not be safe for
ARP (NEIGH_CB is used) or other protocols, may be we have
to add skb->protocol == htons(ETH_P_IP) check here because
ip_route_input() can be called for different protocols.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net-next 1/2] udp: Do not require sock in udp_tunnel_xmit_skb
From: Or Gerlitz @ 2015-01-21 20:57 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Thomas Graf, Linux Netdev List
In-Reply-To: <CA+mtBx80QDU4FJfzh0WATTuaDGS4vaBv0H0r8AfmKjw0rk1f3A@mail.gmail.com>
On Wed, Jan 21, 2015 at 12:24 AM, Tom Herbert <therbert@google.com> wrote:
> vxlan_xmit_one calls udp_flow_src_port to get a source port value
> based on the encapsulated flow.
OK, got it -- does a by-product of invoking udp_flow_src_port on the
skb is having an hash mark on the skb which is based on the inner
packet and can (is?) used for TX queue selection over MQ devices?
^ permalink raw reply
* [3.13.y-ckt stable] Patch "xen-netfront: Fix handling packets on compound pages with skb_linearize" has been added to staging queue
From: Kamal Mostafa @ 2015-01-21 20:47 UTC (permalink / raw)
To: Zoltan Kiss
Cc: Wei Liu, Ian Campbell, Paul Durrant, netdev, linux-kernel,
xen-devel, David S. Miller, Stefan Bader, Kamal Mostafa,
kernel-team
This is a note to let you know that I have just added a patch titled
xen-netfront: Fix handling packets on compound pages with skb_linearize
to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
This patch is scheduled to be released in version 3.13.11-ckt15.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.13.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
------
>From 7d113a745b53b4ff8fe7eac931bbab376d66993e Mon Sep 17 00:00:00 2001
From: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Mon, 11 Aug 2014 18:32:23 +0100
Subject: xen-netfront: Fix handling packets on compound pages with
skb_linearize
commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d upstream.
There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets dropped. The reason is that netback maps these slots to a frag in the
frags array, which is limited by size. Having so many slots can occur since
compound pages were introduced, as the ring protocol slice them up into
individual (non-compound) page aligned slots. The theoretical worst case
scenario looks like this (note, skbs are limited to 64 Kb here):
linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
using 2 slots
first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
end and the beginning of a page, therefore they use 3 * 15 = 45 slots
last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
Although I don't think this 51 slots skb can really happen, we need a solution
which can deal with every scenario. In real life there is only a few slots
overdue, but usually it causes the TCP stream to be blocked, as the retry will
most likely have the same buffer layout.
This patch solves this problem by linearizing the packet. This is not the
fastest way, and it can fail much easier as it tries to allocate a big linear
area for the whole packet, but probably easier by an order of magnitude than
anything else. Probably this code path is not touched very frequently anyway.
Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Paul Durrant <paul.durrant@citrix.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David S. Miller <davem@davemloft.net>
BugLink: http://bugs.launchpad.net/bugs/1317811
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
---
drivers/net/xen-netfront.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d58830b..a3ed8de 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -568,9 +568,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
slots = DIV_ROUND_UP(offset + len, PAGE_SIZE) +
xennet_count_skb_frag_slots(skb);
if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
- net_alert_ratelimited(
- "xennet: skb rides the rocket: %d slots\n", slots);
- goto drop;
+ net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d bytes\n",
+ slots, skb->len);
+ if (skb_linearize(skb))
+ goto drop;
}
spin_lock_irqsave(&np->tx_lock, flags);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Jesse Gross @ 2015-01-21 20:35 UTC (permalink / raw)
To: Tom Herbert; +Cc: Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx-v5dvX-OPGeWJb6uwQGhJ5T6iewD83xJGqXb+Ggf+LQw@mail.gmail.com>
On Wed, Jan 21, 2015 at 11:45 AM, Tom Herbert <therbert@google.com> wrote:
>> I used bare metal intel servers. All VXLAN tests were done using linux
>> kernel device without any VMs. All STT tests are done using OVS bridge
>> and STT port.
>>
> So right off the bat you're running the baseline differently than the
> target. Anyway, I cannot replicate your numbers for VXLAN, I see much
> better performance and this with pretty old servers and dumb NICs. I
> suspect you might not have GSO/GRO properly enabled, but instead of
> trying to debug your setup, I'd rather restate my request that you
> provide a network interface to STT so we can do our own fair
> comparison.
If I had to guess, I suspect the difference is that UDP RSS wasn't
enabled, since it doesn't come that way out of the box. Regardless,
you can clearly see a significant difference in single core
performance and CPU consumption.
STT has been fairly well known in network virtualization circles for
the past few years and has some large deployments, so the reported
performance is not a fluke. I remember Pankaj from Microsoft also
mentioning to you that they weren't able to get performance to
reasonable level without TSO. Totally different environment obviously
but same reasoning.
>>>> VXLAN:
>>>> CPU
>>>> Client: 1.6
>>>> Server: 14.2
>>>> Throughput: 5.6 Gbit/s
>>>>
>>>> VXLAN with rcsum:
>>>> CPU
>>>> Client: 0.89
>>>> Server: 12.4
>>>> Throughput: 5.8 Gbit/s
>>>>
>>>> STT:
>>>> CPU
>>>> Client: 1.28
>>>> Server: 4.0
>>>> Throughput: 9.5 Gbit/s
>>>>
>>> 9.5Gbps? Rounding error or is this 40Gbps or larger than 1500 byte MTU?
>>>
>> Nope, its same as VXLAN setup, 10Gbps NIC with 1500MTU.
>>
> That would exceed that theoretical maximum for TCP over 10Gbps
> Ethernet. How are you measuring throughput? How many bytes of protocol
> headers are in STT case?
For large packet cases, STT actually has less header overhead compared
to the unencapsulated traffic stream. This is because for a group of
STT packets generated by a TSO burst from the guest there is only a
single copy of the inner header. Even though TCP headers are used for
encapsulation, there are no options - as opposed to the inner headers,
which typically contain timestamps. Over the course of the ~45 packets
that could be generated from a maximum sized transmission, this
results in negative encapsulation overhead.
I would recommend you take a look at the draft if you haven't already:
http://tools.ietf.org/html/draft-davie-stt-06
It is currently in the final stages of the RFC publication process.
^ permalink raw reply
* Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
From: Skidmore, Donald C @ 2015-01-21 20:27 UTC (permalink / raw)
To: Hiroshi Shimamoto, David Laight, Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, Hayato Momma, linux-kernel@vger.kernel.org
In-Reply-To: <7F861DC0615E0C47A872E6F3C5FCDDBD05E090FE@BPXM14GP.gisp.nec.co.jp>
> -----Original Message-----
> From: Hiroshi Shimamoto [mailto:h-shimamoto@ct.jp.nec.com]
> Sent: Wednesday, January 21, 2015 4:18 AM
> To: David Laight; Skidmore, Donald C; Bjørn Mork
> Cc: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy
> Jong; linux-kernel@vger.kernel.org; Hayato Momma
> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
> mode control
>
> > Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast
> > promiscuous mode control
> >
> > From: Hiroshi Shimamoto
> > > My concern is what is the real issue that VF multicast promiscuous mode
> can cause.
> > > I think there is the 4k entries to filter multicast address, and the
> > > current ixgbe/ixgbevf can turn all bits on from VM. That is almost same as
> enabling multicast promiscuous mode.
> > > I mean that we can receive all multicast addresses by an onerous
> operation in untrusted VM.
> > > I think we should clarify what is real security issue in this context.
> >
> > If you are worried about passing un-enabled multicasts to users then
> > what about doing a software hash of received multicasts and checking
> > against an actual list of multicasts enabled for that hash entry.
> > Under normal conditions there is likely to be only a single address to check.
> >
> > It may (or may not) be best to use the same hash as any hashing
> > hardware filter uses.
>
> thanks for the comment. But I don't think that is the point.
>
> I guess, introducing VF multicast promiscuous mode seems to add new
> privilege to peek every multicast packet in VM and that doesn't look good.
> On the other hand, I think that there has been the same privilege in the
> current ixgbe/ixgbevf implementation already. Or I'm reading the code
> wrongly.
> I'd like to clarify what is the issue of allowing to receive all multicast packets.
Allowing a VM to give itself the privilege of seeing every multicast packet could be seen as a hole in VM isolation. Now if the host system allows this policy I don't see this as an issue as someone specifically allowed this to happen and then must not be concerned. We could even log that it has occurred, which I believe your patch did do. The issue is also further muddied, as you mentioned above, since some of these multicast packets are leaking anyway (the HW currently uses a 12 bit mask). It's just that this change would greatly enlarge that hole from a fraction to all multicast packets.
>
> thanks,
> Hiroshi
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Eric Dumazet @ 2015-01-21 20:22 UTC (permalink / raw)
To: Tom Herbert; +Cc: Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx-v5dvX-OPGeWJb6uwQGhJ5T6iewD83xJGqXb+Ggf+LQw@mail.gmail.com>
On Wed, 2015-01-21 at 11:45 -0800, Tom Herbert wrote:
> > I used bare metal intel servers. All VXLAN tests were done using linux
> > kernel device without any VMs. All STT tests are done using OVS bridge
> > and STT port.
> >
> So right off the bat you're running the baseline differently than the
> target. Anyway, I cannot replicate your numbers for VXLAN, I see much
> better performance and this with pretty old servers and dumb NICs. I
> suspect you might not have GSO/GRO properly enabled, but instead of
> trying to debug your setup, I'd rather restate my request that you
> provide a network interface to STT so we can do our own fair
> comparison.
I have not read specs nor the patch, but I would expect that with a TCP
stream, you simply can coalesce as many inner segments as you want.
So you could build a single TSO packet containing 400 'messages' of 160
bytes or so.
Something that a datagram tunneling cannot really do, assuming you want
full offloading support.
^ permalink raw reply
* Re: [patch] bridge: simplify br_getlink() a bit
From: Stephen Hemminger @ 2015-01-21 20:02 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, bridge, netdev, kernel-janitors
In-Reply-To: <20150121092235.GA19206@mwanda>
On Wed, 21 Jan 2015 12:22:35 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Static checkers complain that we should maybe set "ret" before we do the
> "goto out;". They interpret the NULL return from br_port_get_rtnl() as
> a failure and forgetting to set the error code is a common bug in this
> situation.
>
> The code is confusing but it's actually correct. We are returning zero
> deliberately. Let's re-write it a bit to be more clear.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index 528cf27..3875ea51 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -311,17 +311,14 @@ errout:
> int br_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> struct net_device *dev, u32 filter_mask)
> {
> - int err = 0;
> struct net_bridge_port *port = br_port_get_rtnl(dev);
>
> if (!port && !(filter_mask & RTEXT_FILTER_BRVLAN) &&
> !(filter_mask & RTEXT_FILTER_BRVLAN_COMPRESSED))
> - goto out;
> + return 0;
>
> - err = br_fill_ifinfo(skb, port, pid, seq, RTM_NEWLINK, NLM_F_MULTI,
> - filter_mask, dev);
> -out:
> - return err;
> + return br_fill_ifinfo(skb, port, pid, seq, RTM_NEWLINK, NLM_F_MULTI,
> + filter_mask, dev);
> }
>
> static int br_vlan_info(struct net_bridge *br, struct net_bridge_port *p,
That looks fine.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-01-21 19:45 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CALnjE+po5gy7g8ftmiNcnrN_gRL9tzCRHNtn=fxUafFikKB1rg@mail.gmail.com>
> I used bare metal intel servers. All VXLAN tests were done using linux
> kernel device without any VMs. All STT tests are done using OVS bridge
> and STT port.
>
So right off the bat you're running the baseline differently than the
target. Anyway, I cannot replicate your numbers for VXLAN, I see much
better performance and this with pretty old servers and dumb NICs. I
suspect you might not have GSO/GRO properly enabled, but instead of
trying to debug your setup, I'd rather restate my request that you
provide a network interface to STT so we can do our own fair
comparison.
>> Another thing to consider in your analysis is the performance with
>> flows using small packets. STT should demonstrate better performance
>> with bulk flows since LSO and LRO are better performing relative to
>> GSO and GRO. But for flows with small packets, I don't see how there
>> could be any performance advantage. We already have ways to leverage
>> simple UDP checksum offload with UDP encapsulations, seems like STT
>> might just represent unnecessary header overhead in those cases.
>>
> All tunneling protocol has performance issue with small packet, I do
> not see how is it related to STT patch. STT also make use of checksum
> offload, so there should not be much overhead.
>
Given the pervasiveness of these patches and the fact that this is
"modifying" the definition of TCP protocol we see on the wire, I would
like to see more effort into analyzing performance and effects of this
encapsulation. I assume that STT is intended to be used for small
packets so it seems entirely reasonable to ask what exactly the
performance effects are for that case. It's really not that hard to
run some performance numbers with comparisons (TCP_RR, TCP_STREAM,
TCP_CRR, with IPv6, etc.) and report them in the patch set
description. You can look at FOU, GUE, vxlan rco, and the checksum
patches I did for some examples.
>>> VXLAN:
>>> CPU
>>> Client: 1.6
>>> Server: 14.2
>>> Throughput: 5.6 Gbit/s
>>>
>>> VXLAN with rcsum:
>>> CPU
>>> Client: 0.89
>>> Server: 12.4
>>> Throughput: 5.8 Gbit/s
>>>
>>> STT:
>>> CPU
>>> Client: 1.28
>>> Server: 4.0
>>> Throughput: 9.5 Gbit/s
>>>
>> 9.5Gbps? Rounding error or is this 40Gbps or larger than 1500 byte MTU?
>>
> Nope, its same as VXLAN setup, 10Gbps NIC with 1500MTU.
>
That would exceed that theoretical maximum for TCP over 10Gbps
Ethernet. How are you measuring throughput? How many bytes of protocol
headers are in STT case?
Thanks,
Tom
> Thanks.
^ permalink raw reply
* Re: [PATCH net-next v13 5/5] openvswitch: Add support for unique flow IDs.
From: Joe Stringer @ 2015-01-21 19:29 UTC (permalink / raw)
To: Pravin Shelar; +Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev, LKML
In-Reply-To: <CALnjE+qHjf5djBybPQUzoR_+dxDskQJQwtgvSN=G5NW9pckETw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 21 January 2015 at 10:31, Pravin Shelar <pshelar@nicira.com> wrote:
> On Tue, Jan 20, 2015 at 10:32 AM, Joe Stringer <joestringer@nicira.com> wrote:
>> Previously, flows were manipulated by userspace specifying a full,
>> unmasked flow key. This adds significant burden onto flow
>> serialization/deserialization, particularly when dumping flows.
>>
>> This patch adds an alternative way to refer to flows using a
>> variable-length "unique flow identifier" (UFID). At flow setup time,
>> userspace may specify a UFID for a flow, which is stored with the flow
>> and inserted into a separate table for lookup, in addition to the
>> standard flow table. Flows created using a UFID must be fetched or
>> deleted using the UFID.
>>
>> All flow dump operations may now be made more terse with OVS_UFID_F_*
>> flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to
>> omit the flow key from a datapath operation if the flow has a
>> corresponding UFID. This significantly reduces the time spent assembling
>> and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags
>> enabled, the datapath only returns the UFID and statistics for each flow
>> during flow dump, increasing ovs-vswitchd revalidator performance by 40%
>> or more.
>>
>> Signed-off-by: Joe Stringer <joestringer@nicira.com>
>
> Its almost ready. But I saw minor issues,
> few checkpatch.pl failures.
> in ovs_flow_cmd_new() we should use unmasked key to lookup in flow
> table for legacy case.
Thanks for review, I can send out a fresh version soon. Should I
resend the whole series or is just a new version of this patch
sufficient?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* offline for a bit
From: David Miller @ 2015-01-21 19:11 UTC (permalink / raw)
To: netdev; +Cc: sparclinux
I came down with a very bad stomache virus last night and have been
doing nothing but sleeping and making trips to the bathroom since
yesterday afternoon.
I'm getting better, but it will be a few days before I can catch up
with everything.
Thanks in advance for your patience.
^ permalink raw reply
* Re: [PATCH 11/11] usb: core: fix a race with usb_queue_reset_device()
From: Alan Stern @ 2015-01-21 18:52 UTC (permalink / raw)
To: Olivier Sobrie
Cc: Jan Dumon, Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150121135512.GA9889@hposo>
On Wed, 21 Jan 2015, Olivier Sobrie wrote:
> I tested your patch. It also fixes the problem I observed.
> You can drop mine.
>
> For your info:
>
> My test consists in powering down a usb hso modem while one of its
> serial port is opened. It leads to two URB failures, each urb callback
> queues a reset.
> Without your fix (or without the one I sent), a crash happens after
> less than ~20 power up/down sequences. With your fix, after more than
> 1000 power up/down I don't see any crash.
Okay, I'll submit the patch. Thanks for testing it.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v2] net: stmmac: add BQL support
From: Eric Dumazet @ 2015-01-21 18:37 UTC (permalink / raw)
To: Beniamino Galvani
Cc: David S. Miller, Giuseppe Cavallaro, Florian Fainelli, Dave Taht,
netdev, linux-kernel
In-Reply-To: <1421863647-20048-1-git-send-email-b.galvani@gmail.com>
On Wed, 2015-01-21 at 19:07 +0100, Beniamino Galvani wrote:
> Add support for Byte Queue Limits to the STMicro MAC driver.
>
> Tested on a Amlogic S802 quad Cortex-A9 board, where the use of BQL
> decreases the latency of a high priority ping from ~12ms to ~1ms when
> the 100Mbit link is saturated by 20 TCP streams.
>
> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
> ---
> Changes since v1:
> - don't access skb->len after the start of DMA transmission in
> stmmac_xmit(), to avoid potential use after free in case tx_lock is
> removed in the future
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH net-next v13 5/5] openvswitch: Add support for unique flow IDs.
From: Pravin Shelar @ 2015-01-21 18:31 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <1421778772-11879-6-git-send-email-joestringer@nicira.com>
On Tue, Jan 20, 2015 at 10:32 AM, Joe Stringer <joestringer@nicira.com> wrote:
> Previously, flows were manipulated by userspace specifying a full,
> unmasked flow key. This adds significant burden onto flow
> serialization/deserialization, particularly when dumping flows.
>
> This patch adds an alternative way to refer to flows using a
> variable-length "unique flow identifier" (UFID). At flow setup time,
> userspace may specify a UFID for a flow, which is stored with the flow
> and inserted into a separate table for lookup, in addition to the
> standard flow table. Flows created using a UFID must be fetched or
> deleted using the UFID.
>
> All flow dump operations may now be made more terse with OVS_UFID_F_*
> flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to
> omit the flow key from a datapath operation if the flow has a
> corresponding UFID. This significantly reduces the time spent assembling
> and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags
> enabled, the datapath only returns the UFID and statistics for each flow
> during flow dump, increasing ovs-vswitchd revalidator performance by 40%
> or more.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Its almost ready. But I saw minor issues,
few checkpatch.pl failures.
in ovs_flow_cmd_new() we should use unmasked key to lookup in flow
table for legacy case.
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Pravin Shelar @ 2015-01-21 18:30 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx9yM+C8GeEHOGTHPVxNB3fJd7LQG0RaC3jywrO9_tQ58A@mail.gmail.com>
On Wed, Jan 21, 2015 at 8:51 AM, Tom Herbert <therbert@google.com> wrote:
> On Wed, Jan 21, 2015 at 1:08 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>> On Tue, Jan 20, 2015 at 3:06 PM, Tom Herbert <therbert@google.com> wrote:
>>> On Tue, Jan 20, 2015 at 12:25 PM, Pravin B Shelar <pshelar@nicira.com> wrote:
>>>> Following patch series adds support for Stateless Transport
>>>> Tunneling protocol.
>>>> STT uses TCP segmentation offload available in most of NIC. On
>>>> packet xmit STT driver appends STT header along with TCP header
>>>> to the packet. For GSO packet GSO parameters are set according
>>>> to tunnel configuration and packet is handed over to networking
>>>> stack. This allows use of segmentation offload available in NICs
>>>>
>>>> Netperf unidirectional test gives ~9.4 Gbits/s performance on 10Gbit
>>>> NIC with 1500 byte MTU with two TCP streams.
>>>>
>>> Having packets marked TCP which really aren't TCP is a rather scary
>>> prospect to deploy in a real data center (TCP is kind of an important
>>> protocol ;-) ). Can you give some more motivation on this, more data
>>> that shows what the benefits are and how this compares to equivalent
>>> encapsulation protocols that implement GRO and GSO.
>>>
>> There are multi-year deployments of STT, So it is already in real data center.
>> Biggest advantage is STT does not need new NIC with tunnel offload.
>> Any NIC that supports TCP offload can be used to achieve better
>> performance.
>>
>> Following are numbers you asked for.
>> Setup: net-next branch on server and client.
>> netperf: TCP unidirectional tests with 5 streams. Numbers are averaged
>> over 3 runs of 50 sec.
>>
> Please provides more details on your configuration so that others
> might be able to reproduce your results. Also, it would be quite
> helpful if you could implement STT as a normal network interface like
> VXLAN does so that we can isolate performance of the protocol. For
> instance I have no problem getting line rate with VXLAN using 5
> streams with or without RCO in my testing. I assume you tested with
> OVS and maybe VMs which may have a significant impact beyond the
> protocol changes.
>
I used bare metal intel servers. All VXLAN tests were done using linux
kernel device without any VMs. All STT tests are done using OVS bridge
and STT port.
> Another thing to consider in your analysis is the performance with
> flows using small packets. STT should demonstrate better performance
> with bulk flows since LSO and LRO are better performing relative to
> GSO and GRO. But for flows with small packets, I don't see how there
> could be any performance advantage. We already have ways to leverage
> simple UDP checksum offload with UDP encapsulations, seems like STT
> might just represent unnecessary header overhead in those cases.
>
All tunneling protocol has performance issue with small packet, I do
not see how is it related to STT patch. STT also make use of checksum
offload, so there should not be much overhead.
>> VXLAN:
>> CPU
>> Client: 1.6
>> Server: 14.2
>> Throughput: 5.6 Gbit/s
>>
>> VXLAN with rcsum:
>> CPU
>> Client: 0.89
>> Server: 12.4
>> Throughput: 5.8 Gbit/s
>>
>> STT:
>> CPU
>> Client: 1.28
>> Server: 4.0
>> Throughput: 9.5 Gbit/s
>>
> 9.5Gbps? Rounding error or is this 40Gbps or larger than 1500 byte MTU?
>
Nope, its same as VXLAN setup, 10Gbps NIC with 1500MTU.
Thanks.
^ permalink raw reply
* [PATCH v2] net: stmmac: add BQL support
From: Beniamino Galvani @ 2015-01-21 18:07 UTC (permalink / raw)
To: David S. Miller
Cc: Giuseppe Cavallaro, Florian Fainelli, Dave Taht, netdev,
linux-kernel, Beniamino Galvani
Add support for Byte Queue Limits to the STMicro MAC driver.
Tested on a Amlogic S802 quad Cortex-A9 board, where the use of BQL
decreases the latency of a high priority ping from ~12ms to ~1ms when
the 100Mbit link is saturated by 20 TCP streams.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
---
Changes since v1:
- don't access skb->len after the start of DMA transmission in
stmmac_xmit(), to avoid potential use after free in case tx_lock is
removed in the future
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 118a427..1d74313 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1097,6 +1097,7 @@ static int init_dma_desc_rings(struct net_device *dev, gfp_t flags)
priv->dirty_tx = 0;
priv->cur_tx = 0;
+ netdev_reset_queue(priv->dev);
stmmac_clear_descriptors(priv);
@@ -1300,6 +1301,7 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
static void stmmac_tx_clean(struct stmmac_priv *priv)
{
unsigned int txsize = priv->dma_tx_size;
+ unsigned int bytes_compl = 0, pkts_compl = 0;
spin_lock(&priv->tx_lock);
@@ -1356,6 +1358,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
priv->hw->mode->clean_desc3(priv, p);
if (likely(skb != NULL)) {
+ pkts_compl++;
+ bytes_compl += skb->len;
dev_consume_skb_any(skb);
priv->tx_skbuff[entry] = NULL;
}
@@ -1364,6 +1368,9 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
priv->dirty_tx++;
}
+
+ netdev_completed_queue(priv->dev, pkts_compl, bytes_compl);
+
if (unlikely(netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv))) {
netif_tx_lock(priv->dev);
@@ -1418,6 +1425,7 @@ static void stmmac_tx_err(struct stmmac_priv *priv)
(i == txsize - 1));
priv->dirty_tx = 0;
priv->cur_tx = 0;
+ netdev_reset_queue(priv->dev);
priv->hw->dma->start_tx(priv->ioaddr);
priv->dev->stats.tx_errors++;
@@ -2048,6 +2056,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
if (!priv->hwts_tx_en)
skb_tx_timestamp(skb);
+ netdev_sent_queue(dev, skb->len);
priv->hw->dma->enable_dma_transmission(priv->ioaddr);
spin_unlock(&priv->tx_lock);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: mv643xx_eth: Fix highmem support in non-TSO egress path
From: Russell King - ARM Linux @ 2015-01-21 17:40 UTC (permalink / raw)
To: Ezequiel Garcia; +Cc: netdev, David Miller, B38611, fabio.estevam
In-Reply-To: <1421844850-30886-3-git-send-email-ezequiel.garcia@free-electrons.com>
On Wed, Jan 21, 2015 at 09:54:10AM -0300, Ezequiel Garcia wrote:
> Commit 69ad0dd7af22b61d9e0e68e56b6290121618b0fb
> Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Date: Mon May 19 13:59:59 2014 -0300
>
> net: mv643xx_eth: Use dma_map_single() to map the skb fragments
>
> caused a nasty regression by removing the support for highmem skb
> fragments. By using page_address() to get the address of a fragment's
> page, we are assuming a lowmem page. However, such assumption is incorrect,
> as fragments can be in highmem pages, resulting in very nasty issues.
>
> This commit fixes this by using the skb_frag_dma_map() helper,
> which takes care of mapping the skb fragment properly.
This seems fine, so:
> Fixes: 69ad0dd7af22 ("net: mv643xx_eth: Use dma_map_single() to map the skb fragments")
> Reported-by: Russell King <linux@arm.linux.org.uk>
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Thanks.
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/mv643xx_eth.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index a62fc38..0c77f0e 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -879,10 +879,8 @@ static void txq_submit_frag_skb(struct tx_queue *txq, struct sk_buff *skb)
> skb_frag_t *this_frag;
> int tx_index;
> struct tx_desc *desc;
> - void *addr;
>
> this_frag = &skb_shinfo(skb)->frags[frag];
> - addr = page_address(this_frag->page.p) + this_frag->page_offset;
> tx_index = txq->tx_curr_desc++;
> if (txq->tx_curr_desc == txq->tx_ring_size)
> txq->tx_curr_desc = 0;
> @@ -902,8 +900,9 @@ static void txq_submit_frag_skb(struct tx_queue *txq, struct sk_buff *skb)
>
> desc->l4i_chk = 0;
> desc->byte_cnt = skb_frag_size(this_frag);
> - desc->buf_ptr = dma_map_single(mp->dev->dev.parent, addr,
> - desc->byte_cnt, DMA_TO_DEVICE);
> + desc->buf_ptr = skb_frag_dma_map(mp->dev->dev.parent,
> + this_frag, 0, desc->byte_cnt,
> + DMA_TO_DEVICE);
> }
> }
>
> @@ -1065,9 +1064,22 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
> reclaimed++;
> txq->tx_desc_count--;
>
> - if (!IS_TSO_HEADER(txq, desc->buf_ptr))
> - dma_unmap_single(mp->dev->dev.parent, desc->buf_ptr,
> - desc->byte_cnt, DMA_TO_DEVICE);
> + if (!IS_TSO_HEADER(txq, desc->buf_ptr)) {
> +
> + /* The first descriptor is either a TSO header or
> + * the linear part of the skb.
> + */
> + if (desc->cmd_sts & TX_FIRST_DESC)
> + dma_unmap_single(mp->dev->dev.parent,
> + desc->buf_ptr,
> + desc->byte_cnt,
> + DMA_TO_DEVICE);
> + else
> + dma_unmap_page(mp->dev->dev.parent,
> + desc->buf_ptr,
> + desc->byte_cnt,
> + DMA_TO_DEVICE);
> + }
>
> if (cmd_sts & TX_ENABLE_INTERRUPT) {
> struct sk_buff *skb = __skb_dequeue(&txq->tx_skb);
> --
> 2.2.1
>
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Questions about the sh_eth driver and hardware
From: Ben Hutchings @ 2015-01-21 17:24 UTC (permalink / raw)
To: Nobuhiro Iwamatsu, Mitsuhiro Kimura, Hisashi Nakamura,
Yoshihiro Kaneko
Cc: netdev, ct-linux-kernel
I found several more bugs in the sh_eth driver, but for some of them I'm
really unsure what to do. I only have a manual for the R8A7790 (R-Car
H2) and I don't know how all the other supported chips will behave.
Maybe you can answer some of these questions.
1. When freeing packet buffers, we currently try to stop the DMA engines
by clearing EDRRR and EDTRR but we *don't* wait after that. This seems
unsafe because in general register writes are not serialised with DMA.
The R8A7790 (R-Car H2) manual specifically says that the R bit of EDTRR
(aka CXR2) cannot be cleared by writing to it. I think that we could
stop TX DMA by clearing the active flags of all the descriptors and then
polling the R bit until it clears. What do you think?
As for RX DMA, I think we should wait some time after clearing the R bit
that we can be sure is long enough to transfer one packet. Do you know
how long that could be?
2. In case of a Receive Descriptor Empty error (RDE), we currently read
the RDFAR register to find the next descriptor the DMA engine will use.
But this register is not documented for the R8A7790 and the driver does
not define an offset for it on R-Car chips. The manual doesn't say how
to set the address of the next descriptor to use. Maybe we should
assume that R-Car chips will never skip descriptors after RDE?
Ben.
^ permalink raw reply
* Re: BW regression after "tcp: refine TSO autosizing"
From: Eric Dumazet @ 2015-01-21 17:01 UTC (permalink / raw)
To: David Laight
Cc: 'Rick Jones', Dave Taht, Eyal Perry, Yuchung Cheng,
Neal Cardwell, Eyal Perry, Or Gerlitz, Linux Netdev List,
Amir Vadai, Yevgeny Petrilin, Saeed Mahameed, Ido Shamay,
Amir Ancel
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD027E@AcuExch.aculab.com>
On Wed, 2015-01-21 at 12:26 +0000, David Laight wrote:
> From: Of Rick Jones
> > >> Are you saying that at long last, delayed acks as we knew them are
> > >> dead, dead, dead?
> > >
> > > Sorry, I can not parse what you are saying.
> > >
> > > In case you missed it, it has nothing to do with delayed ACK but GRO on
> > > receiver.
> >
> > Dave - assuming I've interpreted Eric's comments correctly, I believe
> > the answer to your question is No. Your desire for a world brimming
> > with ack-every-other purity has not been fulfilled :)
> >
> > However, the engineers formerly at Mentat are probably pleased that a
> > functional near-equivalent to their ACK avoidance heuristic has ended-up
> > being implemented and tacitly accepted, albeit by the back door :)
>
> I must recheck something I discovered a while back with more recent kernels.
> There has been a bad interaction between 'slow start' and 'delayed acks'
> when nagle is disabled on 0 RTT local links with uni-directional traffic.
>
> 'Slow start' would refuse to send more than 4 messages until it received
> an ack (rather than 4 mss of data).
> The receiving system wouldn't send an ack until the timer expired
> (or several mss of data were received) by which time the sender could have
> a lot of data queued.
>
> Due to the 0 RTT and bursty nature of the data 'slow start' happened
> all the time.
Following packetdrill test suggests that current kernel send up to 10
messages without having to wait for any ACK
(IW10)
// Set up production and experiment configs
`../common/defaults.sh`
// Establish a connection.
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0
0.100 < S 0:0(0) win 32792 <mss 1460,nop,wscale 7>
0.100 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 6>
0.110 < . 1:1(0) ack 1 win 257
0.110 accept(3, ..., ...) = 4
0.200 %{ assert tcpi_snd_cwnd == 10 }%
+0 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
+0.01 write(4, ..., 100) = 100
+0 > P. 1:101(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 101:201(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 201:301(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 301:401(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 401:501(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 501:601(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 601:701(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 701:801(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 801:901(100) ack 1
+0.01 write(4, ..., 100) = 100
+0 > P. 901:1001(100) ack 1
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-01-21 16:51 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CALnjE+rSXpPftiG4Vw3azkN2s2-Ey6ZcZr9Bv422pOdwrvU=tw@mail.gmail.com>
On Wed, Jan 21, 2015 at 1:08 AM, Pravin Shelar <pshelar@nicira.com> wrote:
> On Tue, Jan 20, 2015 at 3:06 PM, Tom Herbert <therbert@google.com> wrote:
>> On Tue, Jan 20, 2015 at 12:25 PM, Pravin B Shelar <pshelar@nicira.com> wrote:
>>> Following patch series adds support for Stateless Transport
>>> Tunneling protocol.
>>> STT uses TCP segmentation offload available in most of NIC. On
>>> packet xmit STT driver appends STT header along with TCP header
>>> to the packet. For GSO packet GSO parameters are set according
>>> to tunnel configuration and packet is handed over to networking
>>> stack. This allows use of segmentation offload available in NICs
>>>
>>> Netperf unidirectional test gives ~9.4 Gbits/s performance on 10Gbit
>>> NIC with 1500 byte MTU with two TCP streams.
>>>
>> Having packets marked TCP which really aren't TCP is a rather scary
>> prospect to deploy in a real data center (TCP is kind of an important
>> protocol ;-) ). Can you give some more motivation on this, more data
>> that shows what the benefits are and how this compares to equivalent
>> encapsulation protocols that implement GRO and GSO.
>>
> There are multi-year deployments of STT, So it is already in real data center.
> Biggest advantage is STT does not need new NIC with tunnel offload.
> Any NIC that supports TCP offload can be used to achieve better
> performance.
>
> Following are numbers you asked for.
> Setup: net-next branch on server and client.
> netperf: TCP unidirectional tests with 5 streams. Numbers are averaged
> over 3 runs of 50 sec.
>
Please provides more details on your configuration so that others
might be able to reproduce your results. Also, it would be quite
helpful if you could implement STT as a normal network interface like
VXLAN does so that we can isolate performance of the protocol. For
instance I have no problem getting line rate with VXLAN using 5
streams with or without RCO in my testing. I assume you tested with
OVS and maybe VMs which may have a significant impact beyond the
protocol changes.
Another thing to consider in your analysis is the performance with
flows using small packets. STT should demonstrate better performance
with bulk flows since LSO and LRO are better performing relative to
GSO and GRO. But for flows with small packets, I don't see how there
could be any performance advantage. We already have ways to leverage
simple UDP checksum offload with UDP encapsulations, seems like STT
might just represent unnecessary header overhead in those cases.
> VXLAN:
> CPU
> Client: 1.6
> Server: 14.2
> Throughput: 5.6 Gbit/s
>
> VXLAN with rcsum:
> CPU
> Client: 0.89
> Server: 12.4
> Throughput: 5.8 Gbit/s
>
> STT:
> CPU
> Client: 1.28
> Server: 4.0
> Throughput: 9.5 Gbit/s
>
9.5Gbps? Rounding error or is this 40Gbps or larger than 1500 byte MTU?
Thanks,
Tom
> Thanks,
> Pravin.
^ permalink raw reply
* Re: unclear ipv6 redirect message (was Re: [PATCH v3 2/3] mfd: lubbock_io: add lubbock_io board)
From: Russell King - ARM Linux @ 2015-01-21 16:46 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, Robert Jarzmik, Lee Jones, Mark Rutland, devicetree,
Samuel Ortiz, Pawel Moll, Ian Campbell, Dmitry Eremin-Solenikov,
linux-kernel, Haojian Zhuang, Rob Herring, Arnd Bergmann,
linux-arm-kernel, Kumar Gala, Daniel Mack
In-Reply-To: <1421858444.10574.14.camel@perches.com>
On Wed, Jan 21, 2015 at 08:40:44AM -0800, Joe Perches wrote:
> On Wed, 2015-01-21 at 16:11 +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 21, 2015 at 08:05:21AM -0800, Joe Perches wrote:
> > > (adding netdev)
> >
> > I wasn't actually reporting that as an issue; I was using it as an
> > example. It's from a very old kernel (2.6.27.21) which I run on one
> > of my old x86 machines.
>
> It's still the same code.
> If the message can be improved, why not do it?
I assume you're taking the responsibility to test anything that comes
out of this then?
I'm not; I tried updating the kernel on the machine to 2.6.32 many
years ago and that was a no-go because of userspace (udev)
incompatibilities.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ 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