* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Arend van Spriel @ 2015-01-23 18:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Sergei Shtylyov, Fu, Zhonghui, brudley, Franky Lin, meuleman,
linville, pieterpg, hdegoede, wens, linux-wireless,
brcm80211-dev-list, netdev, linux-kernel@vger.kernel.org
In-Reply-To: <87y4otldln.fsf@kamboji.qca.qualcomm.com>
On 01/23/15 16:29, Kalle Valo wrote:
> Arend van Spriel<arend@broadcom.com> writes:
>
>> On 01/22/15 14:54, Sergei Shtylyov wrote:
>>> Hello.
>>>
>>> On 1/22/2015 4:49 PM, Kalle Valo wrote:
>>>
>>>>> > From 04d3fa673897ca4ccbea6c76836d0092dba2484a Mon Sep 17 00:00:00 2001
>>>>> From: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>>>>> Date: Tue, 20 Jan 2015 11:14:13 +0800
>>>>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>>
>>>>> WiFi chip has 2 SDIO functions, and PM core will trigger
>>>>> twice suspend/resume operations for one WiFi chip to do
>>>>> the same things. This patch avoid this case.
>>>
>>>>> Acked-by: Arend van Spriel<arend@broadcom.com>
>>>>> Acked-by: Sergei Shtylyov<sergei.shtylyov@cogentembedded.com>
>>>>> Acked-by: Kalle Valo<kvalo@codeaurora.org>
>>>>> Signed-off-by: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>>>
>>>> I don't remember giving Acked-by to this (or for matter to anything for
>>>> a long time). What about Sergei or Arend?
>>>
>>> I haven't ACK'ed this patch either.
>>
>> I did ACK the initial patch and felt it still valid for this 'V2' patch.
>
> Ok, thanks. So the patch is good, Zhonghui just needs to remove the two
> acked-by lines.
Indeed.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: James Hogan @ 2015-01-23 18:12 UTC (permalink / raw)
To: Stathis Voukelatos
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stathis Voukelatos,
abrestic-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <1422007621-13567-1-git-send-email-stathis.voukelatos-zgcZaY4qg+21Qrn1Bg8BZw@public.gmane.org>
Hi,
A few general things below (I'll leave the actual networking bits for
others to comment about).
On Friday 23 January 2015 10:07:01 Stathis Voukelatos wrote:
> ---
> .../bindings/net/linn-ether-packet-sniffer.txt | 27 ++
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> MAINTAINERS | 7 +
> drivers/net/Kconfig | 2 +
> drivers/net/Makefile | 1 +
> drivers/net/pkt-sniffer/Kconfig | 23 ++
> drivers/net/pkt-sniffer/Makefile | 8 +
> drivers/net/pkt-sniffer/backends/ether/channel.c | 366 ++++++++++++++++++
> drivers/net/pkt-sniffer/backends/ether/channel.h | 76 ++++
> drivers/net/pkt-sniffer/backends/ether/hw.h | 46 +++
> drivers/net/pkt-sniffer/backends/ether/platform.c | 231 +++++++++++
> drivers/net/pkt-sniffer/core/dev_table.c | 124 ++++++
> drivers/net/pkt-sniffer/core/module.c | 37 ++
> drivers/net/pkt-sniffer/core/nl.c | 427 +++++++++++++++++++++
> drivers/net/pkt-sniffer/core/nl.h | 34 ++
> drivers/net/pkt-sniffer/core/snf_core.h | 64 +++
> include/linux/pkt_sniffer.h | 89 +++++
Probably worth splitting this up a bit into a series of multiple
logically separate patches. E.g. the vendor prefix, the core, the ether
backend and dt bindings.
> diff --git a/drivers/net/pkt-sniffer/Kconfig b/drivers/net/pkt-sniffer/Kconfig
> new file mode 100644
> index 0000000..26b4f98
> --- /dev/null
> +++ b/drivers/net/pkt-sniffer/Kconfig
> @@ -0,0 +1,23 @@
> +menuconfig PKT_SNIFFER
> + tristate "Linn packet sniffer support"
Should the kconfig symbol have linn in the name, or should the prompt
not have lin in the name?
> + ---help---
> + Say Y to add support for Linn packet sniffer drivers.
> +
> + The core driver can also be built as a module. If so, the module
> + will be called snf_core.
> +
> +if PKT_SNIFFER
Just make PKT_SNIFFER_ETHER depend first on PKT_SNIFFER, then it'll
appear nested within it in menuconfig.
> +
> +config PKT_SNIFFER_ETHER
> + tristate "Ethernet packet sniffer"
> + depends on MIPS
worth adding || COMPILE_TEST to get compile coverage on x86 allmodconfig
builds, or does it have hard dependencies on the MIPS arch?
> + default n
No need, n is default
> + help
> + Say Y here if you want to use the Linn Ethernet packet sniffer
> + module. It can be found in the upcoming Pistachio SoC by
> + Imagination Technologies.
> +
> + The driver can also be built as a module. If so, the module
> + will be called snf_ether.
> +
> +endif # PKT_SNIFFER
> +/* Called when the packet sniffer device is bound with the driver */
> +static int esnf_driver_probe(struct platform_device *pdev)
> +{
> + struct ether_snf *esnf;
> + struct resource *res;
> + int ret, irq;
> + u32 fifo_blk_words;
> + void __iomem *regs;
> + struct device_node *ofn = pdev->dev.of_node;
> +
> + /* Allocate the device data structure */
> + esnf = devm_kzalloc(&pdev->dev, sizeof(*esnf), GFP_KERNEL);
> + if (!esnf)
> + return -ENOMEM;
> +
> + /* Retrieve and remap register memory space */
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + if (!res)
> + return -ENODEV;
No need for this check. devm_ioremap_resource does it for you.
> +
> + regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> +
> +static const struct of_device_id esnf_of_match_table[] = {
> + { .compatible = "linn,eth-sniffer", .data = NULL },
Nit: not strictly necessary to initialise .data since it's static.
Cheers
James
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, esnf_of_match_table);
> +
> +static struct platform_driver esnf_platform_driver = {
> + .driver = {
> + .name = esnf_driver_name,
> + .of_match_table = esnf_of_match_table,
> + },
> + .probe = esnf_driver_probe,
> + .remove = esnf_driver_remove,
> +};
> +
> +module_platform_driver(esnf_platform_driver);
> +
> +MODULE_DESCRIPTION("Linn Ethernet Packet Sniffer");
> +MODULE_AUTHOR("Linn Products Ltd");
> +MODULE_LICENSE("GPL v2");
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: David Ahern @ 2015-01-23 18:23 UTC (permalink / raw)
To: Brian Haley, netdev; +Cc: hannes
In-Reply-To: <54C27220.7020600@hp.com>
On 1/23/15 9:09 AM, Brian Haley wrote:
> On 01/14/2015 02:17 PM, David Ahern wrote:
>> Currently, ipv6 addresses are flushed when the interface is configured down:
>>
>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
>> [root@f20 ~]# ip addr show dev eth1
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>> inet6 2000:11:1:1::1/64 scope global tentative
>> valid_lft forever preferred_lft forever
>> [root@f20 ~]# ip link set dev eth1 up
>> [root@f20 ~]# ip link set dev eth1 down
>> [root@f20 ~]# ip addr show dev eth1
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>>
>> Add a new sysctl to make this behavior optional. Setting defaults to flush
>> addresses to maintain backwards compatibility. When reset flushing is bypassed:
>>
>> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
>> [root@f20 ~]# ip addr show dev eth1
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>> inet6 2000:11:1:1::1/64 scope global tentative
>> valid_lft forever preferred_lft forever
>> [root@f20 ~]# ip link set dev eth1 up
>> [root@f20 ~]# ip link set dev eth1 down
>> [root@f20 ~]# ip addr show dev eth1
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>> inet6 2000:11:1:1::1/64 scope global
>> valid_lft forever preferred_lft forever
>> inet6 fe80::4:11ff:fe22:3301/64 scope link
>> valid_lft forever preferred_lft forever
>
> I think this was brought up in a previous thread on this, but don't you have to
> do DAD on these addresses once the interface comes back up? Some other system
> could have come along, done DAD, succeeded, and is now using it. Or does the
> use of this flag assume the user is Ok without doing DAD, and will deal with the
> fallout?
You have the same problem today, don't you? Current code allows an IPv6
address to be configured on interface in the down state. The intent of
this sysctl is to allow that address to stay on an up-down cycle.
I don't have a strong IPv6 background so the first email thread and this
RFC patch are both asking first and foremost if there is any harm in
this behavior. None has been raised - so far. To maintain backwards
compatibility this is a new option which when reset allows the addresses
to be retained (not flushed).
David
^ permalink raw reply
* RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
From: Skidmore, Donald C @ 2015-01-23 18:24 UTC (permalink / raw)
To: Alexander Duyck, Hiroshi Shimamoto, Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, David Laight,
Hayato Momma
In-Reply-To: <54C1F5BF.30105@gmail.com>
> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> Sent: Thursday, January 22, 2015 11:18 PM
> To: Hiroshi Shimamoto; Skidmore, Donald C; Bjørn Mork
> Cc: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy
> Jong; linux-kernel@vger.kernel.org; David Laight; Hayato Momma
> Subject: Re: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
> mode control
>
> On 01/22/2015 04:32 PM, Hiroshi Shimamoto wrote:
> >> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast
> >> promiscuous mode control
> >>> "Skidmore, Donald C" <donald.c.skidmore@intel.com> writes:
> >>>
> >>>> My hang up is more related to: without the nob to enable it (off by
> >>>> default) we are letting one VF dictate policy for all the other VFs
> >>>> and the PF. If one VF needs to be in promiscuous multicast so is
> >>>> everyone else. Their stacks now needs to deal with all the extra
> >>>> multicast packets. As you point out this might not be a direct
> >>>> concern for isolation in that the VM could have 'chosen' to join
> >>>> any Multicast group and seen this traffic. My concern over
> >>>> isolation is one VF has chosen that all the other VM now have to
> >>>> see this multicast traffic.
> >>> Apologies if this question is stupid, but I just have to ask about
> >>> stuff I don't understand...
> >>>
> >>> Looking at the proposed implementation, the promiscous multicast
> >>> flag seems to be a per-VF flag:
> >>>
> >>> +int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf,
> >>> +bool
> >>> +setting) {
> >>> + struct ixgbe_adapter *adapter = netdev_priv(netdev);
> >>> + struct ixgbe_hw *hw = &adapter->hw;
> >>> + u32 vmolr;
> >>> +
> >>> + if (vf >= adapter->num_vfs)
> >>> + return -EINVAL;
> >>> +
> >>> + adapter->vfinfo[vf].mc_promisc_enabled = setting;
> >>> +
> >>> + vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
> >>> + if (setting) {
> >>> + e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
> >>> + vmolr |= IXGBE_VMOLR_MPE;
> >>> + } else {
> >>> + e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
> >>> + vmolr &= ~IXGBE_VMOLR_MPE;
> >>> + }
> >>> +
> >>> + IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>>
> >>> I haven't read the data sheet, but I took a quick look at the
> >>> excellent high level driver docs:
> >>> http://www.intel.com/content/dam/doc/design-guide/82599-sr-iov-
> drive
> >>> r-
> >>> companion-guide.pdf
> >>>
> >>> It mentions "Multicast Promiscuous Enable" in its "Thoughts for
> >>> Customization" section:
> >>>
> >>> 7.1 Multicast Promiscuous Enable
> >>>
> >>> The controller has provisions to allow each VF to be put into
> >>> Multicast Promiscuous mode. The Intel reference driver does not
> >>> configure this option .
> >>>
> >>> The capability can be enabled/disabled by manipulating the MPE
> >>> field (bit
> >>> 28) of the PF VF L2 Control Register (PFVML2FLT – 0x0F000)
> >>>
> >>> and showing a section from the data sheet describing the "PF VM L2
> >>> Control Register - PFVML2FLT[n] (0x0F000 + 4 * n, n=0...63; RW)"
> >>>
> >>> To me it looks like enabling Promiscuos Multicast for a VF won't
> >>> affect any other VF at all. Is this really not the case?
> >>>
> >>>
> >>>
> >>> Bjørn
> >> Clearly not a dumb question at all and I'm glad you mentioned that.
> >> :) I was going off the assumption, been awhile since I read the
> >> patch, that the patch was using FCTRL.MPE or MANC.MCST_PASS_L2
> which would turn multicast promiscuous on for everyone. Since the patch is
> using PFVML2FLT.MPE this lessens my concern over effect on the entire
> system.
> > I believe the patches for this VF multicast promiscuous mode is per VF.
> >
> >> That said I still would prefer having a way to override this behavior on the
> PF, although I admit my argument is weaker.
> >> I'm still concerned about a VF changing the behavior of the PF
> >> without any way to prevent it. This might be one part philosophical
> >> (PF sets policy not the VF) but this still could have a noticeable
> >> effect on the overall system. If any other VFs (or the PF) are
> >> receiving MC packets these will have to be replicated which will be a
> >> performance hit. When we use the MC hash this is limited vs. when
> anyone is in MC promiscuous every MC packet used by another pool would
> be replicated. I could imagine in some environments (i.e. public clouds)
> where you don't trust what is running in your VM you might what to block
> this from happening.
> > I understand your request and I'm thinking to submit the patches
> > 1) Add new mbox API between ixgbe/ixgbevf to turn MC promiscuous on,
> > and enables it when ixgbevf needs over 30 MC addresses.
> > 2) Add a policy knob to prevent enabling it from the PF.
> >
> > Does it seem okay?
>
> I would advise that if such a knob is added it should be set to disabled by
> default. The main problem with supporting that many multicast addresses
> per VF is that you run the risk for flooding the PCIe interface on the network
> adapter if too many adapters were to go into such a mode.
>
This was my understanding as well. Someone would have to "choose" to allow VM to enter this mode, meaning off by default.
> > BTW, I'm bit worried about to use ndo interface for 2) because adding
> > a new hook makes core code complicated.
> > Is it really reasonable to do it with ndo?
> > I haven't find any other suitable method to do it, right now. And
> > using ndo VF hook looks standard way to control VF functionality.
> > Then, I think it's the best way to implement this policy in ndo hook.
>
> The ndo is probably the only way to go on this. It is how past controls for the
> VF network functionality have been implemented.
>
> >> In some ways it is almost the mirror image of the issue you brought up:
> >>
> >> Adding a new hook for this seems over-complicated to me. And it
> >> still doesn't solve the real problems that
> >> a) the user has to know about this limit, and
> >> b) manually configure the feature
> >>
> >> My reverse argument might be that if this happens automatically. It
> >> might take the VM provider a long time to realize performance has
> >> taken a hit because some VM asked to join 31 multicast groups and
> entered MC promiscuous. Then only to find that they have no way to block
> such behavior.
> >>
> >> Maybe I wouldn't as concerned if the patch author could provide some
> >> performance results to show this won't have as a negative effect as I'm
> afraid it might?
> > Hm, what kind of test case would you like to have?
> > The user A who has 30 MC addresses vs the user B who has 31 MC
> > addresses, which means that MC promiscuous mode, and coming MC
> packets the user doesn't expect?
> >
> > thanks,
> > Hiroshi
>
> The question I would have is how many of these interfaces do you expect to
> have supporting the expanded multicast mode? As it currently stands
> multicast traffic has the potential to flood the adapter, greatly reduce the
> overall throughput, and add extra workload to the PF and all VFs.
> For example if several VFs enable this feature, and then someone on the
> network sends a stream of multicast traffic what happens to the CPU load for
> the host system?
>
> Also how many addresses beyond 30 is it you require? An alternative to
> adding multicast promiscuous might be to consider extending the mailbox
> API to support sending more than 30 addresses via something such as a
> multi-part multicast configuration message. The fm10k driver already has
> logic similar to this as it adds addresses 1 at a time though a separate Switch
> interface API between the PF and the Switch. You might be able to reuse
> some of that code to reach beyond the 30 address limit.
I think this would be a much safer approach and probably scale well for small sets. However I don't think it would work for Hiroshi's use case. If I remember correctly he wanted 1000's of MC groups per VM. I imagine there would be considerable overhead even loading up our 4K hash table 1 address at a time, likewise with that many address wouldn't this just be pretty much the same as being in multicast promiscuous. Still this might be an interesting approach to support those needing only a few MC groups over the limit.
Alex's point is worth reiterating, this will effect performance. Have you tested this out under load and still see the results you can live with?
-Don Skidmore <donald.c.skidmore@intel.com>
>
> - Alex
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Tom Herbert @ 2015-01-23 18:25 UTC (permalink / raw)
To: Jesse Gross; +Cc: Pravin B Shelar, David Miller, Linux Netdev List
In-Reply-To: <CAEP_g=-sVSwewV=7qAYQNtBRVSrUOAjNCpfwniNq_WPg2FVpFA@mail.gmail.com>
On Fri, Jan 23, 2015 at 9:38 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Fri, Jan 23, 2015 at 8:58 AM, 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.
>>>
>> The reason you're able to get 9.4 Gbit/s with an L2 encapsulation
>> using STT is that it has less protocol overhead per packet when doing
>> segmentation compared to VXLAN (without segmentation STT packets will
>> have more overhead than VXLAN).
>>
>> A VXLAN packet with TCP/IP has headers
>> IP|UDP|VXLAN|Ethernet|IP|TCP+options. Assuming TCP is stuffed with
>> options, this is 20+8+8+16+20+40=112 bytes, or 7.4% MTU. Each STT
>> segment created in GSO, other than the first, has just IP|TCP headers
>> which is 20+20=40 bytes or 2.6% MTU. So this explains throughput
>> differences between VXLAN and STT.
>
> Tom, what performance do you see with a single stream of VXLAN running
> on net-next with default configuration? The difference in numbers
> being posted here is greater than a few percent caused by protocol
> overheard.
Please look at the data I posted with the VXLAN RCO patches.
TCP/IP 10Gbps with 1500 byte MTU, 14 bytes for Ethernet header, 15
bytes for preamble, FCS, IPG, and no TCP options gives 9.54Gbps
maximum throughput. About what you see in STT minus overhead in first
segment.
TCP/IPv4 on VXLAN with TCP options gives max throughout 9.09Gbps,
TCP/IPv6 over VXLAN then gives 8.96Gbps. Pretty much what we see give
or take a few bytes for TCP options and rounding error.
Tom
^ permalink raw reply
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Vlad Yasevich @ 2015-01-23 18:30 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Sun Paul, linux-sctp, netdev, linux-kernel, tuexen
In-Reply-To: <54C2807E.8080607@redhat.com>
On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
>>>> I would like to check the behave in LKSCTP.
>>>>
>>>> we are running DIAMETER message over SCTP, and we have set the
>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>>
>>>> We noticed that when remote peer have retry to send the same request
>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>> "association exceeded its max_retrans count".
>>>>
>>>> We would like to know whether this is the correct behavior? is there
>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>> being sent?
>>>
>>> I don't recall the RFC saying to send an ABORT, but let me double
>>> check in the mean time.
>>
>> The RFC is silent on the matter. The abort got added in 3.8 so
>> it's been there for a while.
>
> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> exceeded") added the behaviour.
>
>>> Hmm, untested, but could you try something like that?
>>>
>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>> index fef2acd..5ce198d 100644
>>> --- a/net/sctp/sm_sideeffect.c
>>> +++ b/net/sctp/sm_sideeffect.c
>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>> SCTP_ULPEVENT(event));
>>>
>>> - if (asoc->overall_error_count >= asoc->max_retrans) {
>>> + if (asoc->overall_error_count >= asoc->max_retrans &&
>>> + error != SCTP_ERROR_NO_ERROR) {
>>> abort = sctp_make_violation_max_retrans(asoc, chunk);
>>> if (abort)
>>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>>
>> This would pretty much stop all ABORTs due to excessive rtx. Might
>> as well take the code out :).
>>
>> I was a bit concerned about this ABORT when it went in.
>
> So effectively, if I understand the argument from the commit, the
> assumption is that the ABORT would never reach the peer anyway, but
> is a way for tcpdump users to see on the wire that rtx limit has
> been exceeded and since there's not mentioned anything in the RFC
> about this, it doesn't break it. Hm.
>
Additionally I seem to recall BSD sending this type of ABORT for pretty
much the same reason.
-vlad
> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
>
> Thanks,
> Daniel
^ permalink raw reply
* Re: [PATCH net-next] bonding: handle more gso types
From: Tom Herbert @ 2015-01-23 18:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Or Gerlitz
In-Reply-To: <1422021446.29618.8.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Jan 23, 2015 at 5:57 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 5a7baa78851b ("bonding: Advertize vxlan offload features when
> supported"), Or Gerlitz added support conditional vxlan offload.
>
> In this patch I also add support for GRE, IPIP and SIT tunnels,
> but we allow a bonding device to not require segmentation,
> as it is always better to make this segmentation at the very last stage,
> if a particular slave device requires it.
>
> Tested:
>
> ethtool -K bond0 tx-gre-segmentation off
>
> super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
> 7538.32
>
> ethtool -K bond0 tx-gre-segmentation on
>
> super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
> 10200.5
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> drivers/net/bonding/bond_main.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 0dceba1a2ba15f4706922a5423f680e7cd17ef77..1e837fceb3fb7b739c543b0d5babc4da4797caf3 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -998,7 +998,10 @@ static netdev_features_t bond_fix_features(struct net_device *dev,
> NETIF_F_HIGHDMA | NETIF_F_LRO)
>
> #define BOND_ENC_FEATURES (NETIF_F_ALL_CSUM | NETIF_F_SG | NETIF_F_RXCSUM |\
> - NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL)
> + NETIF_F_TSO)
> +
Is there any reason not to add NETIF_F_GSO_UDP_TUNNEL_CSUM and
NETIF_F_GSO_UDP_REMCSUM also?
> +#define BOND_ENC_ALWAYS (NETIF_F_GSO_GRE | NETIF_F_GSO_IPIP | \
> + NETIF_F_GSO_SIT | NETIF_F_GSO_UDP_TUNNEL)
>
> static void bond_compute_features(struct bonding *bond)
> {
> @@ -1034,7 +1037,7 @@ static void bond_compute_features(struct bonding *bond)
>
> done:
> bond_dev->vlan_features = vlan_features;
> - bond_dev->hw_enc_features = enc_features;
> + bond_dev->hw_enc_features = enc_features | BOND_ENC_ALWAYS;
> bond_dev->hard_header_len = max_hard_header_len;
> bond_dev->gso_max_segs = gso_max_segs;
> netif_set_gso_max_size(bond_dev, gso_max_size);
> @@ -4010,7 +4013,7 @@ void bond_setup(struct net_device *bond_dev)
> NETIF_F_HW_VLAN_CTAG_FILTER;
>
> bond_dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
> - bond_dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
> + bond_dev->hw_features |= BOND_ENC_ALWAYS;
> bond_dev->features |= bond_dev->hw_features;
> }
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Michael Tuexen @ 2015-01-23 18:36 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Vlad Yasevich, Sun Paul, linux-sctp, netdev, linux-kernel
In-Reply-To: <54C2807E.8080607@redhat.com>
> On 23 Jan 2015, at 18:10, Daniel Borkmann <dborkman@redhat.com> wrote:
>
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
>>>> I would like to check the behave in LKSCTP.
>>>>
>>>> we are running DIAMETER message over SCTP, and we have set the
>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>>
>>>> We noticed that when remote peer have retry to send the same request
>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>> "association exceeded its max_retrans count".
>>>>
>>>> We would like to know whether this is the correct behavior? is there
>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>> being sent?
>>>
>>> I don't recall the RFC saying to send an ABORT, but let me double
>>> check in the mean time.
>>
>> The RFC is silent on the matter. The abort got added in 3.8 so
>> it's been there for a while.
>
> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> exceeded") added the behaviour.
>
>>> Hmm, untested, but could you try something like that?
>>>
>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>> index fef2acd..5ce198d 100644
>>> --- a/net/sctp/sm_sideeffect.c
>>> +++ b/net/sctp/sm_sideeffect.c
>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>> SCTP_ULPEVENT(event));
>>>
>>> - if (asoc->overall_error_count >= asoc->max_retrans) {
>>> + if (asoc->overall_error_count >= asoc->max_retrans &&
>>> + error != SCTP_ERROR_NO_ERROR) {
>>> abort = sctp_make_violation_max_retrans(asoc, chunk);
>>> if (abort)
>>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>>
>> This would pretty much stop all ABORTs due to excessive rtx. Might
>> as well take the code out :).
>>
>> I was a bit concerned about this ABORT when it went in.
>
> So effectively, if I understand the argument from the commit, the
> assumption is that the ABORT would never reach the peer anyway, but
> is a way for tcpdump users to see on the wire that rtx limit has
> been exceeded and since there's not mentioned anything in the RFC
> about this, it doesn't break it. Hm.
Yepp. It might not reach the peer or it might. If it does it helps
to keep the states in sync. If it doesn't it sometimes helps in
analysing tracefiles. In BSD, we also send it. It is not required,
doesn't harm and is useful in some cases...
Best regards
Michael
>
> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
>
> Thanks,
> Daniel
>
^ permalink raw reply
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Michael Tuexen @ 2015-01-23 18:36 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Daniel Borkmann, Sun Paul, linux-sctp, netdev, linux-kernel
In-Reply-To: <54C2935F.2000105@gmail.com>
> On 23 Jan 2015, at 19:30, Vlad Yasevich <vyasevich@gmail.com> wrote:
>
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
>> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>>> ...
>>>>> I would like to check the behave in LKSCTP.
>>>>>
>>>>> we are running DIAMETER message over SCTP, and we have set the
>>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>>>
>>>>> We noticed that when remote peer have retry to send the same request
>>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>>> "association exceeded its max_retrans count".
>>>>>
>>>>> We would like to know whether this is the correct behavior? is there
>>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>>> being sent?
>>>>
>>>> I don't recall the RFC saying to send an ABORT, but let me double
>>>> check in the mean time.
>>>
>>> The RFC is silent on the matter. The abort got added in 3.8 so
>>> it's been there for a while.
>>
>> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
>> exceeded") added the behaviour.
>>
>>>> Hmm, untested, but could you try something like that?
>>>>
>>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>>> index fef2acd..5ce198d 100644
>>>> --- a/net/sctp/sm_sideeffect.c
>>>> +++ b/net/sctp/sm_sideeffect.c
>>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>>> SCTP_ULPEVENT(event));
>>>>
>>>> - if (asoc->overall_error_count >= asoc->max_retrans) {
>>>> + if (asoc->overall_error_count >= asoc->max_retrans &&
>>>> + error != SCTP_ERROR_NO_ERROR) {
>>>> abort = sctp_make_violation_max_retrans(asoc, chunk);
>>>> if (abort)
>>>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>>>
>>> This would pretty much stop all ABORTs due to excessive rtx. Might
>>> as well take the code out :).
>>>
>>> I was a bit concerned about this ABORT when it went in.
>>
>> So effectively, if I understand the argument from the commit, the
>> assumption is that the ABORT would never reach the peer anyway, but
>> is a way for tcpdump users to see on the wire that rtx limit has
>> been exceeded and since there's not mentioned anything in the RFC
>> about this, it doesn't break it. Hm.
>>
>
> Additionally I seem to recall BSD sending this type of ABORT for pretty
> much the same reason.
Yepp.
Best regards
Michael
>
> -vlad
>
>> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
>>
>> Thanks,
>> Daniel
>
>
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: David Ahern @ 2015-01-23 18:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, hannes
In-Reply-To: <20150122224033.6e2db5ce@urahara>
On 1/22/15 11:40 PM, Stephen Hemminger wrote:
> Would this break existing application expecting a particular semantic
> by listening to netlink? What happens to packets received with the static
> address when interface is down? With IPv4 Linux is mostly a weak host
> model, and IPv6 somewhere in between.
>
> For vendors that control the application stack or have limited number
> of services this would work fine, but what about RHEL?
>
>
The intent of making it a sysctl option is to maintain backwards
compatibility and allow users to take the new functionality if desired -
which includes accepting changes in behavior.
David
^ permalink raw reply
* Re: [PATCH net-next] bonding: handle more gso types
From: Eric Dumazet @ 2015-01-23 18:56 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev, Or Gerlitz
In-Reply-To: <CA+mtBx98Hem6+L1gt9ZK-JDs0f=aNdJakFnGWspoTzdYcAcpBA@mail.gmail.com>
On Fri, 2015-01-23 at 10:33 -0800, Tom Herbert wrote:
> Is there any reason not to add NETIF_F_GSO_UDP_TUNNEL_CSUM and
> NETIF_F_GSO_UDP_REMCSUM also?
I guess there is no reasons, others than me not catching with all these
extra features, and me not being able to test them.
^ permalink raw reply
* Re: [PATCH net-next v3 1/5] netdev: introduce new NETIF_F_HW_NETFUNC_OFFLOAD feature flag for switch device offloads
From: Jiri Pirko @ 2015-01-23 19:05 UTC (permalink / raw)
To: Thomas Graf
Cc: roopa, sfeldma, jhs, bcrl, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <20150123175654.GB25374@casper.infradead.org>
Fri, Jan 23, 2015 at 06:56:54PM CET, tgraf@suug.ch wrote:
>On 01/23/15 at 07:48am, roopa wrote:
>> On 1/23/15, 1:44 AM, Jiri Pirko wrote:
>> >How about rather "HW_DATAPATH_OFFLOAD"? Feels more accurate. By the
>> >name, I still cannot understand what NETFUNC should mean.
>>
>> It was supposed to mean 'network function offload'. sure, will consider
>> HW_DATAPATH_OFFLOAD
>> or if anybody has other suggestions.
>
>I'm still fascinated that the description says 'for all switch asic
>offloads', 'switch drivers', 'switch ports' but we try very hard to
>come up with a different name ;-)
+1
But we'll see in future. I bet that "switch" will stick.
^ permalink raw reply
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Daniel Borkmann @ 2015-01-23 19:05 UTC (permalink / raw)
To: Michael Tuexen; +Cc: Vlad Yasevich, Sun Paul, linux-sctp, netdev, linux-kernel
In-Reply-To: <8BBFBEE6-FA34-4190-BFCB-AB6BEC093774@fh-muenster.de>
On 01/23/2015 07:36 PM, Michael Tuexen wrote:
...
> Yepp. It might not reach the peer or it might. If it does it helps
> to keep the states in sync. If it doesn't it sometimes helps in
> analysing tracefiles. In BSD, we also send it. It is not required,
> doesn't harm and is useful in some cases...
Ok, as the TCB is destroyed in any case, should be fine then.
Thanks,
Daniel
^ permalink raw reply
* Re: [patch net-next RFC] tc: introduce OpenFlow classifier
From: Cong Wang @ 2015-01-23 19:33 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, David Miller, Jamal Hadi Salim
In-Reply-To: <1421933824-17916-1-git-send-email-jiri@resnulli.us>
On Thu, Jan 22, 2015 at 5:37 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> This patch introduces OpenFlow-based filter. So far, the very essential
> packet fields are supported (according to OpenFlow v1.4 spec).
>
> Known issues: skb_flow_dissect hashes out ipv6 addresses. That needs
> to be changed to store them somewhere so they can be used later on.
>
This has large overlap with cls_flow, I suspect we really
need so many flow dissectors? Or, on the other hand, it might
make sense to move the key computing logic to user-space
so that we don't need to add each of them in kernel?
^ permalink raw reply
* Re: wireless: p54: add handling of the signal case
From: Kalle Valo @ 2015-01-23 19:34 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Christian Lamparter, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Nicholas Mc Guire
In-Reply-To: <1421731543-13290-1-git-send-email-der.herr-kA1LtwSENNE@public.gmane.org>
> if(!wait_for_completion_interruptible_timeout(...))
> only handles the timeout case - this patch adds handling the
> signal case the same as timeout.
>
> Signed-off-by: Nicholas Mc Guire <der.herr-kA1LtwSENNE@public.gmane.org>
> Acked-by: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Thanks, applied to wireless-drivers-next.git but I removed "wireless:" from the
title.
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: p54pci: add handling of signal case
From: Kalle Valo @ 2015-01-23 19:37 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Christian Lamparter, linux-wireless, netdev, linux-kernel,
Nicholas Mc Guire
In-Reply-To: <1421731577-13324-1-git-send-email-der.herr@hofr.at>
> if(!wait_for_completion_interruptible_timeout(...))
> only handles the timeout case - this patch adds handling the
> signal case the same as timeout.
>
> Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Thanks, applied to wireless-drivers-next.git. I remove the useless "wireless: "
from the title.
Kalle Valo
^ permalink raw reply
* Re: [v2] atmel: Remove open-coded and wrong strcasecmp
From: Kalle Valo @ 2015-01-23 19:40 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Simon Kelley, Sergei Shtylyov, Rasmus Villemoes, linux-wireless,
netdev, linux-kernel
In-Reply-To: <1421841127-8209-1-git-send-email-linux@rasmusvillemoes.dk>
> The kernel's string library does in fact have strcasecmp, at least
> since ded220bd8f08 ("[STRING]: Move strcasecmp/strncasecmp to
> lib/string.c"). Moreover, this open-coded version is in fact wrong: If
> the strings only differ in their last character, a and b have already
> been incremented to point to the terminating NUL bytes, so they would
> wrongly be treated as equal.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Thanks, applied to wireless-drivers-next.git. I just remove the useless "net:
wireless:" from the title. People, PLEASE stop using that.
Kalle Valo
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: John Fastabend @ 2015-01-23 19:59 UTC (permalink / raw)
To: Thomas Graf
Cc: Jiri Pirko, Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123174609.GA23242@casper.infradead.org>
On 01/23/2015 09:46 AM, Thomas Graf wrote:
> I'm pulling in both branches of the thread here:
>
> On 01/23/15 at 04:56pm, Jiri Pirko wrote:
>> Fri, Jan 23, 2015 at 04:43:48PM CET, john.fastabend@gmail.com wrote:
>>> But with the current API its clear that the rules managed by the
>>> Flow API are in front of 'tc' and 'ovs' on ingress. Just the same
>>> as it is clear 'tc' ingress rules are walked before 'ovs' ingress
>>> rules. On egress it is similarly clear that 'ovs' does a forward
>>> rule to a netdev, then 'tc' fiters+qdisc is run, and finally the
>>> hardware flow api is hit.
>>
>>
>> Seems like this would be resolved by the separe "offload" qdisc.
>
> I'm not sure I understand the offload qdisc yet. My interpretation
> so far is that it would contain childs which *must* be offloaded.
Correct that is my suggestion.
_If_ we want to pursue an embedding inside tc/qdisc for the Flow API
then we need some structure to attach filters and qdisc's that _must_
be offloaded. I have cases where qdisc's on the software dataplane
will be entirely different the qdisc/filter layout on the hardware
dataplane. If you don't do this you end up with a rather strange
array of filters that I don't see anyway to unravel especially
with filters like u32 that have many tables and hardware that has
many tables.
In these cases IMO its going to be easiest to reason about the state
and how to configure it if you have two qdisc/filter attach points. One
for software and one for hardware.
>
> How would one transparently offload tc in this model? e.g. let's
> assume we have a simple prio qdisc with u32 cls:
>
> eth0
> prio
> class
> class
> ...
> u32 ...
> u32 ...
>
> Would you need to attach the prio to an "offload qdisc" to offload
> it or would that happen automatically? How would this looks like to
> user space?
My take is it doesn't happen transparently in general. The user space
has to add the qdisc then subsequently attach flows and actions
explicitly to the hardware qdisc. But I'm confused about what 'tc' has
to say about global pipelines see below,
>
> eth0
> offload
> prio
> u32
> u32
> prio
> u32
> u32
>
> Like this?
>
So if I try to do a mock 'tc' session first creating some software
QOS and filters,
# tc qdisc dev eth0 handle 8001: root mq <- add my mq sw qdisc
# tc qdisc dev eth0 parent 8001:1 fq_codel <- add my fq_codel qdiscs
# tc qdisc dev eth0 parent 8001:2 prio <- one per queue
...
# tc filter add dev p3p2 parent 8001:2 \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
action skbedit priority <- arbitrary filter
[...]
everything above is part of my software dataplane next up add some
hw qdisc's and filters.
# tc qdisc dev eth0 handle hw_dpif: root mq <- add my mq hw qdisc
# tc qdisc show
[...] <- normal output
qdisc mq (hwdpif) 0: dev eth0 ...
So that seems OK to me I have a multiqueue QOS object on top of a
netdev that represents the switch _port_.
But it starts to break when I want to add a filter to the flow table
pipeline _not_ a qdisc on a port. The pipeline is shared between all
ports its a per port queueing discipline which is how the current
'tc' model works?
And here is where I stopped in my initial attempt and decided we needed
a new object the Flow API. But let me try to push it perhaps? So I need
something to represent the actual pipeline not the per port qdisc. A
new 'tc' object called 'tables' perhaps?
# tc tables dev eth0 show
[...]
table: vlan:2
src 1 apply 2 size -1
matches:
in_lport [in_lport (lpm)]
vlan [vid (lpm)]
actions:
set_vlan_id ( u16 vlan_id 0 )
[...]
So the above is just selected output from 'flow' tool command giving a
table description. Then I can use the same syntax as my 'flow' tool but
embedded in 'tc'
# tc tables dev eth0 set_rule prio 1 handle 4 table 2 \
match in_lport.in_lport 1 0xffffffff \
action set_vlan_id 10
This could work but its a very simple embedding of what I have now.
Also I can imagine another qdisc options to offload port filters/qos
automagically from inside 'tc'. This could/should be done regardless
of if the Flow API is embedded in 'tc' IMO. So we can have a bit,
# tc qdisc set dev p3p2 handle 8001: offload
Then we can do some tests and offload flows and rules from 'tc'. but
I hope(?) its clear its not the same operation as the above 'tables'
command that I made up to represent the pipeline. The tables cmd above
lets me work on the pipeline.
>>> The cases I've been experimenting with using Flow API it is clear
>>> on the priority and what rules are being used by looking at counters
>>> and "knowing" the above pipeline mode.
>>>
>>> Although as I type this I think a picture would help and some
>>> documentation.
>
> +1
>
> We need one of those awesome graphs as the netfilter guys had it with
> where the hooks are attached to ;-)
Yes, I'll try to draft something next week. I'm a bit worried my above
example is a bit convoluted without it.
>
> On 01/23/15 at 07:34am, John Fastabend wrote:
>> Now 'xflows' needs to implement the same get operations that exist in
>> this flow API otherwise writing meaningful policies as Thomas points out
>> is crude at best. So this tc classifier supports 'get headers',
>> 'get actions', and 'get tables' and then there associated graphs. All
>> good so far. This is just an embedding of the existing API in the 'tc'
>> netlink family. I've never had any issues with this. Finally you build
>> up the 'get_flow' and 'set_flow' operations I still so no issue with
>> this and its just an embedding of the existing API into a 'tc
>> classifier'. My flow tool becomes one of the classifier tools.
>
> .... if we can get rid of the rtnl lock in the flow mod path ;-)
Well isn't it the qdisc lock here? And its not needed anymore for
filters/actions only qdisc's use it because they are not lock-safe
yet. Its been on my backlog to start replacing the skb lists with
lock-free rings but I haven't got anywhere on this yet.
Although a hardware doesn't really need a queuing discipline its
done in hardware so you could drop the qdisc lock in this case.
>
>> Now what should I attach my filter to? Typically we attach it to qdiscs
>> today. But what does that mean for a switch device? I guess I need an
>> _offloaded qdisc_? I don't want to run the same qdisc in my dataplane
>> of the switch as I run on the ports going into/out of the sw dataplane.
>> Similarly I don't want to run the same set of filters. So at this point
>> I have a set of qdiscs per port to represent the switch dataplane and
>> a set of qdiscs attached to the software dataplane. If people think this
>> is worth doing lets do it. It may get you a nice way to manage QOS while
>> your @ it.
>
> If I interpret this correctly then this would imply that each switch
> port is represented with a net_device as this is what the tc API
> understands.
>
I think this would work for QOS but I'm also confused as I tried to
illustrate above how the global pipeline fits into the 'tc' model where
everything is a port with queues.
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH 3/6] rtlwifi: btcoexist: Add routines for RTL8812AE with single antenna
From: Kalle Valo @ 2015-01-23 20:06 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422033044-7461-4-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>
> The RTL8812AE needs different BT coexistence routines than does the
> RTL8821AE. This patch adds the necessary routines for devices with a
> single antenna.
>
> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.c | 2073 ++++++++++++++++++++
> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.h | 152 ++
> 2 files changed, 2225 insertions(+)
> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.h
>
> diff --git a/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
> new file mode 100644
> index 0000000..11ae66b
> --- /dev/null
> +++ b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
> @@ -0,0 +1,2073 @@
> +/* */
> +/* Description: */
> +/* */
> +/* This file is for 8812a1ant Co-exist mechanism */
> +/* */
> +/* History */
> +/* 2012/11/15 Cosa first check in. */
> +/* */
> +/* */
> +
> +/* */
> +/* include files */
> +/* */
One problem I see is that there's no license on either of the files. It
would be much better if the files had that.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 v3] ipv4: try to cache dst_entries which would cause a redirect
From: Julian Anastasov @ 2015-01-23 20:09 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, Marcelo Leitner, Florian Westphal
In-Reply-To: <996db187263dc0419ea3ab4d6e3fad4c0e0e5b44.1422010254.git.hannes@stressinduktion.org>
Hello,
On Fri, 23 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.
>
> Cc: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: Marcelo Leitner <mleitner@redhat.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks! Looks fine.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
> ---
> v2:
> Julian noticed that v1 did omit the redirect flag in rtnetlink
> queries, fixed. Thanks!
>
> v3:
> Julian noticed that we could accidentally write into NEIGHCB, fixed
> and thanks again!
>
> include/net/ip.h | 11 ++++++-----
> net/ipv4/ip_forward.c | 3 ++-
> net/ipv4/route.c | 9 +++++----
> 3 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/ip.h b/include/net/ip.h
> index 0e5a0ba..14211ea 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
> @@ -39,11 +39,12 @@ struct inet_skb_parm {
> struct ip_options opt; /* Compiled IP options */
> unsigned char flags;
>
> -#define IPSKB_FORWARDED 1
> -#define IPSKB_XFRM_TUNNEL_SIZE 2
> -#define IPSKB_XFRM_TRANSFORMED 4
> -#define IPSKB_FRAG_COMPLETE 8
> -#define IPSKB_REROUTED 16
> +#define IPSKB_FORWARDED BIT(0)
> +#define IPSKB_XFRM_TUNNEL_SIZE BIT(1)
> +#define IPSKB_XFRM_TRANSFORMED BIT(2)
> +#define IPSKB_FRAG_COMPLETE BIT(3)
> +#define IPSKB_REROUTED BIT(4)
> +#define IPSKB_DOREDIRECT BIT(5)
>
> u16 frag_max_size;
> };
> diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c
> index 3a83ce5..787b3c2 100644
> --- a/net/ipv4/ip_forward.c
> +++ b/net/ipv4/ip_forward.c
> @@ -129,7 +129,8 @@ int ip_forward(struct sk_buff *skb)
> * We now generate an ICMP HOST REDIRECT giving the route
> * we calculated.
> */
> - if (rt->rt_flags&RTCF_DOREDIRECT && !opt->srr && !skb_sec_path(skb))
> + if (IPCB(skb)->flags & IPSKB_DOREDIRECT && !opt->srr &&
> + !skb_sec_path(skb))
> ip_rt_send_redirect(skb);
>
> skb->priority = rt_tos2priority(iph->tos);
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 2000110..0c63b2a 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1567,11 +1567,10 @@ 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) &&
> + skb->protocol == htons(ETH_P_IP) &&
> (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;
>
> if (skb->protocol != htons(ETH_P_IP)) {
> /* Not IP (i.e. ARP). Do not create route, if it is
> @@ -2316,6 +2315,8 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src,
> r->rtm_flags = (rt->rt_flags & ~0xFFFF) | RTM_F_CLONED;
> if (rt->rt_flags & RTCF_NOTIFY)
> r->rtm_flags |= RTM_F_NOTIFY;
> + if (IPCB(skb)->flags & IPSKB_DOREDIRECT)
> + r->rtm_flags |= RTCF_DOREDIRECT;
>
> if (nla_put_be32(skb, RTA_DST, dst))
> goto nla_put_failure;
> --
> 2.1.0
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 5/6] rtlwifi: btcoexist: Add routines for RTL8812AE - all configs
From: Kalle Valo @ 2015-01-23 20:12 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422033044-7461-6-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>
> This patch adds the routines used for all antenna configurations.
>
> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
The commit log is REALLY vague...
> +static u8 rtl_btcoex_create_kernel_socket(struct rtl_priv *rtlpriv,
> + u8 is_invite)
> +{
> + struct bt_coex_info *pcoex_info = &rtlpriv->coex_info;
> + s8 kernel_socket_err;
> +
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL,
> + "%s CONNECT_PORT %d\n", __func__, CONNECT_PORT);
> +
> + if (!pcoex_info) {
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL, "coex_info: NULL\n");
> + return _FAIL;
> + }
> +
> + kernel_socket_err = sock_create(PF_INET, SOCK_DGRAM, 0,
> + &pcoex_info->udpsock);
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL,
> + "binding socket, err = %d\n", kernel_socket_err);
> +
> + if (kernel_socket_err < 0) {
> + BTC_PRINT(BTC_MSG_SOCKET, SOCKET_CRITICAL,
> + "Error during creation of socket error:%d\n",
> + kernel_socket_err);
> + return _FAIL;
> + }
> + memset(&pcoex_info->sin, 0, sizeof(pcoex_info->sin));
> + pcoex_info->sin.sin_family = AF_INET;
> + pcoex_info->sin.sin_port = htons(CONNECT_PORT);
> + pcoex_info->sin.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
...and then I see stuff like this. What an earth does this do?
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH 1/1 net-next] dev: add per net_device packet type chains
From: Salam Noureddine @ 2015-01-23 20:07 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Tom Herbert, Jiri Pirko,
Vlad Yasevich, netdev
Cc: Salam Noureddine, Eric W. Biederman
When many pf_packet listeners are created on a lot of interfaces the
current implementation using global packet type lists scales poorly.
This patch adds per net_device packet type lists to fix thi problem.
The patch was originally written by Eric Biederman for linux-2.6.20.
Tested on linux-3.16.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Salam Noureddine <noureddine@arista.com>
---
include/linux/netdevice.h | 2 +
net/core/dev.c | 131 +++++++++++++++++++++++++++++-----------------
2 files changed, 85 insertions(+), 48 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 642d426..3d37c6e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1514,6 +1514,8 @@ struct net_device {
struct list_head napi_list;
struct list_head unreg_list;
struct list_head close_list;
+ struct list_head ptype_all;
+ struct list_head ptype_specific;
struct {
struct list_head upper;
diff --git a/net/core/dev.c b/net/core/dev.c
index 1e325ad..0891d31 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -371,9 +371,10 @@ static inline void netdev_set_addr_lockdep_class(struct net_device *dev)
static inline struct list_head *ptype_head(const struct packet_type *pt)
{
if (pt->type == htons(ETH_P_ALL))
- return &ptype_all;
+ return pt->dev ? &pt->dev->ptype_all : &ptype_all;
else
- return &ptype_base[ntohs(pt->type) & PTYPE_HASH_MASK];
+ return pt->dev ? &pt->dev->ptype_specific :
+ &ptype_base[ntohs(pt->type) & PTYPE_HASH_MASK];
}
/**
@@ -1734,6 +1735,23 @@ static inline int deliver_skb(struct sk_buff *skb,
return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
}
+static inline void deliver_ptype_list_skb(struct sk_buff *skb,
+ struct packet_type **pt,
+ struct net_device *dev, __be16 type,
+ struct list_head *ptype_list)
+{
+ struct packet_type *ptype, *pt_prev = *pt;
+
+ list_for_each_entry_rcu(ptype, ptype_list, list) {
+ if (ptype->type != type)
+ continue;
+ if (pt_prev)
+ deliver_skb(skb, pt_prev, dev);
+ pt_prev = ptype;
+ }
+ *pt = pt_prev;
+}
+
static inline bool skb_loop_sk(struct packet_type *ptype, struct sk_buff *skb)
{
if (!ptype->af_packet_priv || !skb->sk)
@@ -1757,45 +1775,54 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
struct packet_type *ptype;
struct sk_buff *skb2 = NULL;
struct packet_type *pt_prev = NULL;
+ struct list_head *ptype_list = &ptype_all;
rcu_read_lock();
- list_for_each_entry_rcu(ptype, &ptype_all, list) {
+again:
+ list_for_each_entry_rcu(ptype, ptype_list, list) {
/* Never send packets back to the socket
* they originated from - MvS (miquels@drinkel.ow.org)
*/
- if ((ptype->dev == dev || !ptype->dev) &&
- (!skb_loop_sk(ptype, skb))) {
- if (pt_prev) {
- deliver_skb(skb2, pt_prev, skb->dev);
- pt_prev = ptype;
- continue;
- }
+ if (skb_loop_sk(ptype, skb))
+ continue;
- skb2 = skb_clone(skb, GFP_ATOMIC);
- if (!skb2)
- break;
+ if (pt_prev) {
+ deliver_skb(skb2, pt_prev, skb->dev);
+ pt_prev = ptype;
+ continue;
+ }
- net_timestamp_set(skb2);
+ /* need to clone skb, done only once */
+ skb2 = skb_clone(skb, GFP_ATOMIC);
+ if (!skb2)
+ goto out_unlock;
- /* skb->nh should be correctly
- set by sender, so that the second statement is
- just protection against buggy protocols.
- */
- skb_reset_mac_header(skb2);
-
- if (skb_network_header(skb2) < skb2->data ||
- skb_network_header(skb2) > skb_tail_pointer(skb2)) {
- net_crit_ratelimited("protocol %04x is buggy, dev %s\n",
- ntohs(skb2->protocol),
- dev->name);
- skb_reset_network_header(skb2);
- }
+ net_timestamp_set(skb2);
- skb2->transport_header = skb2->network_header;
- skb2->pkt_type = PACKET_OUTGOING;
- pt_prev = ptype;
+ /* skb->nh should be correctly
+ set by sender, so that the second statement is
+ just protection against buggy protocols.
+ */
+ skb_reset_mac_header(skb2);
+
+ if (skb_network_header(skb2) < skb2->data ||
+ skb_network_header(skb2) > skb_tail_pointer(skb2)) {
+ net_crit_ratelimited("protocol %04x is buggy, dev %s\n",
+ ntohs(skb2->protocol),
+ dev->name);
+ skb_reset_network_header(skb2);
}
+
+ skb2->transport_header = skb2->network_header;
+ skb2->pkt_type = PACKET_OUTGOING;
+ pt_prev = ptype;
+ }
+
+ if (ptype_list == &ptype_all) {
+ ptype_list = &dev->ptype_all;
+ goto again;
}
+out_unlock:
if (pt_prev)
pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
rcu_read_unlock();
@@ -2617,7 +2644,7 @@ static int xmit_one(struct sk_buff *skb, struct net_device *dev,
unsigned int len;
int rc;
- if (!list_empty(&ptype_all))
+ if (!list_empty(&ptype_all) || !list_empty(&dev->ptype_all))
dev_queue_xmit_nit(skb, dev);
len = skb->len;
@@ -3615,7 +3642,6 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
struct net_device *orig_dev;
- struct net_device *null_or_dev;
bool deliver_exact = false;
int ret = NET_RX_DROP;
__be16 type;
@@ -3658,11 +3684,15 @@ another_round:
goto skip_taps;
list_for_each_entry_rcu(ptype, &ptype_all, list) {
- if (!ptype->dev || ptype->dev == skb->dev) {
- if (pt_prev)
- ret = deliver_skb(skb, pt_prev, orig_dev);
- pt_prev = ptype;
- }
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev, orig_dev);
+ pt_prev = ptype;
+ }
+
+ list_for_each_entry_rcu(ptype, &skb->dev->ptype_all, list) {
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev, orig_dev);
+ pt_prev = ptype;
}
skip_taps:
@@ -3718,19 +3748,20 @@ ncls:
skb->vlan_tci = 0;
}
+ type = skb->protocol;
+
/* deliver only exact match when indicated */
- null_or_dev = deliver_exact ? skb->dev : NULL;
+ if (likely(!deliver_exact)) {
+ deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
+ &ptype_base[ntohs(type) & PTYPE_HASH_MASK]);
+ }
- type = skb->protocol;
- list_for_each_entry_rcu(ptype,
- &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
- if (ptype->type == type &&
- (ptype->dev == null_or_dev || ptype->dev == skb->dev ||
- ptype->dev == orig_dev)) {
- if (pt_prev)
- ret = deliver_skb(skb, pt_prev, orig_dev);
- pt_prev = ptype;
- }
+ deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
+ &orig_dev->ptype_specific);
+
+ if (unlikely(skb->dev != orig_dev)) {
+ deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
+ &skb->dev->ptype_specific);
}
if (pt_prev) {
@@ -6579,6 +6610,8 @@ void netdev_run_todo(void)
/* paranoia */
BUG_ON(netdev_refcnt_read(dev));
+ BUG_ON(!list_empty(&dev->ptype_all));
+ BUG_ON(!list_empty(&dev->ptype_specific));
WARN_ON(rcu_access_pointer(dev->ip_ptr));
WARN_ON(rcu_access_pointer(dev->ip6_ptr));
WARN_ON(dev->dn_ptr);
@@ -6761,6 +6794,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
INIT_LIST_HEAD(&dev->adj_list.lower);
INIT_LIST_HEAD(&dev->all_adj_list.upper);
INIT_LIST_HEAD(&dev->all_adj_list.lower);
+ INIT_LIST_HEAD(&dev->ptype_all);
+ INIT_LIST_HEAD(&dev->ptype_specific);
dev->priv_flags = IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM;
setup(dev);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Jesse Gross @ 2015-01-23 20:20 UTC (permalink / raw)
To: Tom Herbert; +Cc: Pravin B Shelar, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx87bZBnY_9cgQ7k=xsD0VGZUt0rc9DjhSqhpeH3LZiuFw@mail.gmail.com>
On Fri, Jan 23, 2015 at 10:25 AM, Tom Herbert <therbert@google.com> wrote:
> On Fri, Jan 23, 2015 at 9:38 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Fri, Jan 23, 2015 at 8:58 AM, 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.
>>>>
>>> The reason you're able to get 9.4 Gbit/s with an L2 encapsulation
>>> using STT is that it has less protocol overhead per packet when doing
>>> segmentation compared to VXLAN (without segmentation STT packets will
>>> have more overhead than VXLAN).
>>>
>>> A VXLAN packet with TCP/IP has headers
>>> IP|UDP|VXLAN|Ethernet|IP|TCP+options. Assuming TCP is stuffed with
>>> options, this is 20+8+8+16+20+40=112 bytes, or 7.4% MTU. Each STT
>>> segment created in GSO, other than the first, has just IP|TCP headers
>>> which is 20+20=40 bytes or 2.6% MTU. So this explains throughput
>>> differences between VXLAN and STT.
>>
>> Tom, what performance do you see with a single stream of VXLAN running
>> on net-next with default configuration? The difference in numbers
>> being posted here is greater than a few percent caused by protocol
>> overheard.
>
> Please look at the data I posted with the VXLAN RCO patches.
The data you posted uses 200 streams, so I assume that you are using
multiple CPUs. It's not surprising that you would be able to consume a
10G link in that case. STT can do this with a single stream and less
than 1 core (or alternately handle higher throughput). Claiming that
since both can hit 10G they are same is not accurate.
Discussing performance like this seems a little silly given that the
code is available. Pravin posted some numbers that he got, if you want
to dispute them then why don't you just try running it?
^ permalink raw reply
* Re: [PATCH V2 for 3.19 0/7] Fixes for rtl8192ee
From: Kalle Valo @ 2015-01-23 20:24 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, netdev,
troy_tan@realsil.com.cn >> 谭杭波
In-Reply-To: <54C27975.50501@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> It is too bad that it took so long to get these ready. I think the
> reason that there are not a lot of bug reports is because the
> complaints are all in the GitHub issues for the rtlwifi_new repo, or
> with Ubuntu. If there are any that get filed against Bugzilla, I will
> refer them to that repo.
Ok.
> Driver rtl8192ee was new in 3.18. There had been a previous version in
> staging, but it did not get a lot of usage. I'm not sure if the
> additional usage after 3.18 was due to the driver being in the regular
> tree, or if vendors started using the chips, but the problem reports
> started arriving. All these bugs have been part of rtl8192ee since it
> has been in the kernel, thus they are hard to categorize as
> regressions.
Good. So we are not going backwards in quality, that's most important.
> Push all 7 into -next so that they will be in 3.20. If you think it to
> be prudent, please leave the Cc for stable. That way 3.18 and 3.19
> will eventually get the fixes.
I think that's the best plan, thanks for understanding. The patches are
in my queue and I should apply them within the next few days, unless
anything comes during the review.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 3/6] rtlwifi: btcoexist: Add routines for RTL8812AE with single antenna
From: Larry Finger @ 2015-01-23 20:24 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87r3uljm7o.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On 01/23/2015 02:06 PM, Kalle Valo wrote:
> Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
>
>> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>>
>> The RTL8812AE needs different BT coexistence routines than does the
>> RTL8821AE. This patch adds the necessary routines for devices with a
>> single antenna.
>>
>> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>> ---
>> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.c | 2073 ++++++++++++++++++++
>> .../wireless/rtlwifi/btcoexist/halbtc8812a1ant.h | 152 ++
>> 2 files changed, 2225 insertions(+)
>> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
>> create mode 100644 drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.h
>>
>> diff --git a/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
>> new file mode 100644
>> index 0000000..11ae66b
>> --- /dev/null
>> +++ b/drivers/net/wireless/rtlwifi/btcoexist/halbtc8812a1ant.c
>> @@ -0,0 +1,2073 @@
>> +/* */
>> +/* Description: */
>> +/* */
>> +/* This file is for 8812a1ant Co-exist mechanism */
>> +/* */
>> +/* History */
>> +/* 2012/11/15 Cosa first check in. */
>> +/* */
>> +/* */
>> +
>> +/* */
>> +/* include files */
>> +/* */
>
> One problem I see is that there's no license on either of the files. It
> would be much better if the files had that.
I will add that and send a V2 after I wait a while for any other comments.
Thanks,
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
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