* Re: [PATCH] net/ping: handle protocol mismatching scenario
From: David Miller @ 2014-11-24 21:48 UTC (permalink / raw)
To: a17711
Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, netdev, stable,
gbjc64
In-Reply-To: <1416858248-29258-1-git-send-email-a17711@motorola.com>
From: Jane Zhou <a17711@motorola.com>
Date: Mon, 24 Nov 2014 11:44:08 -0800
> ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
> dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
> sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
> sock will be returned.
> the fix is to "continue" the searching, if no matching, return NULL.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: netdev@vger.kernel.org
> Cc: stable@vger.kernel.org
> Signed-off-by: Jane Zhou <a17711@motorola.com>
> Signed-off-by: Yiwei Zhao <gbjc64@motorola.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net/mlx4: Fix EEH recovery failure
From: Gavin Shan @ 2014-11-24 21:42 UTC (permalink / raw)
To: Amir Vadai; +Cc: Gavin Shan, netdev, Or Gerlitz, davem, yishaih
In-Reply-To: <5472099B.5070105@mellanox.com>
On Sun, Nov 23, 2014 at 06:21:47PM +0200, Amir Vadai wrote:
>On 11/22/2014 12:56 PM, Gavin Shan wrote:
>> The patch fixes couple of EEH recovery failures on PPC PowerNV
>> platform:
>>
>> * Release reserved memory regions in mlx4_pci_err_detected().
>> Otherwise, __mlx4_init_one() fails because of reserving
>> same memory regions recursively.
>> * Disable PCI device in mlx4_pci_err_detected(). Otherwise,
>> pci_enable_device() in __mlx4_init_one() doesn't enable
>> the PCI device because it's already in enabled state indicated
>> by struct pci_dev::enable_cnt.
>> * Don't clear struct mlx4_priv instance in mlx4_pci_err_detected().
>> Otherwise, __mlx4_init_one() runs into kernel crash because
>> of dereferencing to NULL pointer.
>>
>> With the patch applied, EEH recovery for mlx4 adapter succeeds on PPC
>> PowerNV platform.
>>
>> # lspci
>> 0003:0f:00.0 Network controller: Mellanox Technologies \
>> MT27500 Family [ConnectX-3]
>>
>> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
>Hi Gavin,
>
>Yishai (added to the CC) is few days before sending a patchset to fix
>the reset flow and inside it there is a fix to EEH recovery.
>I would be happy if you could wait for the whole reset flow fix by Yishai.
>
Yes, It's not urgent and I can wait. Thanks for the info.
>If you'd like, I can send you the patchset to try. Currently it is under
>review inside Mellanox before being sent to the mailing list.
>
It would be nice to send me the patchset for me to have a try.
Thanks,
Gavin
>Thanks,
>Amir
>
>
>
>
^ permalink raw reply
* Re: [PATCH] net/smsc911x: Add minimal runtime PM support
From: David Miller @ 2014-11-24 21:42 UTC (permalink / raw)
To: geert+renesas; +Cc: steve.glendinning, netdev, linux-pm, linux-sh, linux-kernel
In-Reply-To: <1416855497-6479-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Mon, 24 Nov 2014 19:58:17 +0100
> Add minimal runtime PM support (enable on probe, disable on remove), to
> ensure proper operation with a parent device that uses runtime PM.
>
> This is needed on systems where the external bus controller module of
> the SoC is contained in a PM domain and/or has a gateable functional
> clock. In such cases, before accessing any device connected to the
> external bus, the PM domain must be powered up, and/or the functional
> clock must be enabled, which is typically handled through runtime PM by
> the bus controller driver.
>
> An example of this is the kzm9g development board, where an smsc9220
> Ethernet controller is connected to the Bus State Controller (BSC) of a
> Renesas sh73a0 SoC.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied to net-next, thanks!
^ permalink raw reply
* Re: [PATCH net-next] tipc: add tipc_netlink.h to uapi Kbuild
From: David Miller @ 2014-11-24 21:25 UTC (permalink / raw)
To: richard.alpe; +Cc: netdev
In-Reply-To: <1416835494-7655-1-git-send-email-richard.alpe@ericsson.com>
From: <richard.alpe@ericsson.com>
Date: Mon, 24 Nov 2014 14:24:54 +0100
> From: Richard Alpe <richard.alpe@ericsson.com>
>
> tipc_netlink.h is the user-space header for the new netlink api. It
> was accidentally left out of the uapi Kbuild list when the api was
> added.
>
> Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/mlx4: Fix EEH recovery failure
From: Or Gerlitz @ 2014-11-24 21:17 UTC (permalink / raw)
To: Gavin Shan; +Cc: Linux Netdev List, Amir Vadai, David Miller
On Sat, Nov 22, 2014 at 12:56 PM, Gavin Shan <gwshan@linux.vnet.ibm.com> wrote:
> The patch fixes couple of EEH recovery failures on PPC PowerNV
> platform:
> * Don't clear struct mlx4_priv instance in mlx4_pci_err_detected().
> Otherwise, __mlx4_init_one() runs into kernel crash because
> of dereferencing to NULL pointer.
I don't see this change in the patch, I see no-clearing of mlx4_priv
in __mlx4_unload_one - please clarify, also is this patch
based/targeted on the net or net-next tree?
> With the patch applied, EEH recovery for mlx4 adapter succeeds on PPC
> PowerNV platform.
>
> # lspci
> 0003:0f:00.0 Network controller: Mellanox Technologies \
> MT27500 Family [ConnectX-3]
>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
> index 90de6e1..e118ac9 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
> @@ -2809,7 +2809,6 @@ static void mlx4_unload_one(struct pci_dev *pdev)
> kfree(dev->caps.qp1_proxy);
> kfree(dev->dev_vfs);
>
> - memset(priv, 0, sizeof(*priv));
> priv->pci_dev_data = pci_dev_data;
> priv->removed = 1;
> }
> @@ -2900,6 +2899,8 @@ static pci_ers_result_t mlx4_pci_err_detected(struct pci_dev *pdev,
> pci_channel_state_t state)
> {
> mlx4_unload_one(pdev);
> + pci_release_regions(pdev);
> + pci_disable_device(pdev);
>
> return state == pci_channel_io_perm_failure ?
> PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_NEED_RESET;
> --
> 1.8.3.2
>
> --
> 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: [PATCH net-next] rhashtable: Check for count mismatch while iterating in selftest
From: David Miller @ 2014-11-24 21:17 UTC (permalink / raw)
To: tgraf; +Cc: netdev
In-Reply-To: <20668a4b2ff01138f5b1d5b3b59650790e504c00.1416828807.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Mon, 24 Nov 2014 12:37:58 +0100
> Verify whether both the lock and RCU protected iterators see all
> test entries before and after expanding and shrinking has been
> performed. Also verify whether the number of entries in the hashtable
> remains stable during expansion and shrinking.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH] af_packet: fix sparse warning
From: David Miller @ 2014-11-24 21:16 UTC (permalink / raw)
To: mst; +Cc: linux-kernel, dborkman, edumazet, atzm, hannes, therbert, netdev
In-Reply-To: <1416828696-3989-1-git-send-email-mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 24 Nov 2014 13:32:16 +0200
> af_packet produces lots of these:
> net/packet/af_packet.c:384:39: warning: incorrect type in return expression (different modifiers)
> net/packet/af_packet.c:384:39: expected struct page [pure] *
> net/packet/af_packet.c:384:39: got struct page *
>
> this seems to be because sparse does not realize that _pure
> refers to function, not the returned pointer.
>
> Tweak code slightly to avoid the warning.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, please report the sparse bug if you haven't already.
Thanks.
^ permalink raw reply
* Re: [PATCH] xen-netback: do not report success if backend_create_xenvif() fails
From: David Miller @ 2014-11-24 21:14 UTC (permalink / raw)
To: khoroshilov
Cc: wei.liu2, ian.campbell, xen-devel, netdev, linux-kernel,
ldv-project
In-Reply-To: <1416826680-19145-1-git-send-email-khoroshilov@ispras.ru>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Mon, 24 Nov 2014 13:58:00 +0300
> If xenvif_alloc() or xenbus_scanf() fail in backend_create_xenvif(),
> xenbus is left in offline mode but netback_probe() reports success.
>
> The patch implements propagation of error code for backend_create_xenvif().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next] tc_vlan: fix type of tcfv_push_vid
From: David Miller @ 2014-11-24 21:12 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs
In-Reply-To: <1416825026-4628-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 24 Nov 2014 11:30:26 +0100
> Should be u16. So fix it to kill the sparse warning.
>
> Fixes: c7e2b9689ef8136 "sched: introduce vlan action"
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net] ipv6: gre: fix wrong skb->protocol in WCCP
From: David Miller @ 2014-11-24 21:11 UTC (permalink / raw)
To: dborkman; +Cc: hannes, netdev, yuri.chislov, xeb
In-Reply-To: <1416824715-28733-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Mon, 24 Nov 2014 11:25:15 +0100
> From: Yuri Chislov <yuri.chislov@gmail.com>
>
> When using GRE redirection in WCCP, it sets the wrong skb->protocol,
> that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.
>
> Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
> Cc: Dmitry Kozlov <xeb@mail.ru>
> Signed-off-by: Yuri Chislov <yuri.chislov@gmail.com>
> Tested-by: Yuri Chislov <yuri.chislov@gmail.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> Also checked back with Dmitry, it was a copy-paste error from the
> IPv4 implementation.
Good catch, applied, thanks Faniel.
^ permalink raw reply
* Re: [PATCH net-next] tipc: fix sparse warnings in new nl api
From: David Miller @ 2014-11-24 21:10 UTC (permalink / raw)
To: richard.alpe; +Cc: netdev
In-Reply-To: <1416823829-19277-1-git-send-email-richard.alpe@ericsson.com>
From: <richard.alpe@ericsson.com>
Date: Mon, 24 Nov 2014 11:10:29 +0100
> From: Richard Alpe <richard.alpe@ericsson.com>
>
> Fix sparse warnings about non-static declaration of static functions
> in the new tipc netlink API.
>
> Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net_test_tools] route_bench: Fix bug in DST_ITERATE option
From: David Miller @ 2014-11-24 21:09 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev
In-Reply-To: <1416816819-17310-1-git-send-email-subramanian.vijay@gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Mon, 24 Nov 2014 00:13:39 -0800
> While setting option for dst_addr_stride, flags should be set for
> FLAG_DST_ITERATE not FLAG_SRC_ITERATE.
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
This does not apply to the 'net' tree.
^ permalink raw reply
* Re: [PATCH v2] Add support of Cavium Liquidio ethernet adapters
From: David Miller @ 2014-11-24 21:08 UTC (permalink / raw)
To: f.fainelli
Cc: rvatsavayi, netdev, derek.chickles, satananda.burla,
felix.manlunas, raghu.vatsavayi
In-Reply-To: <54739C92.5070309@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 24 Nov 2014 13:01:06 -0800
> On 11/23/2014 07:19 PM, Raghu Vatsavayi wrote:
>> +if LIQUIDIO
>> +
>> +config LIQUIDIO_NAPI
>> + bool "Enable NAPI for LiquidIO"
>> + default y
>> + ---help---
>> + NAPI is a new driver API designed to reduce CPU and interrupt load
>> + when the driver is receiving lots of packets from the card. You
>> + would only disable this feature in very specific instances, like
>> + an application that very rapidly sets up and tears down connections.
>> +
>> + If in doubt, say Y.
>
> You probably do not want to offer a non-NAPI variant, pretty much all
> drivers have NAPI built-in now.
+1.
>> +config LIQUIDIO_DEBUG
>> + int "Debug level for LiquidIO"
>> + range 0 4
>> + default 0
>
> This should be moved to dynamic_debug/ethtools' msglvl control knob.
+1
^ permalink raw reply
* Re: [PATCH 00/17] netfilter/ipvs updates for net-next
From: David Miller @ 2014-11-24 21:01 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1416835674-11871-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 24 Nov 2014 14:27:37 +0100
> The following patchset contains Netfilter updates for your net-next
> tree, this includes the NAT redirection support for nf_tables, the
> cgroup support for nft meta and conntrack zone support for the connlimit
> match. Coming after those, a bunch of sparse warning fixes, missing
> netns bits and cleanups. More specifically, they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH v2] Add support of Cavium Liquidio ethernet adapters
From: Florian Fainelli @ 2014-11-24 21:01 UTC (permalink / raw)
To: Raghu Vatsavayi, davem
Cc: netdev, Derek Chickles, Satanand Burla, Felix Manlunas,
Raghu Vatsavayi
In-Reply-To: <1416799190-23789-1-git-send-email-rvatsavayi@caviumnetworks.com>
On 11/23/2014 07:19 PM, Raghu Vatsavayi wrote:
> +if LIQUIDIO
> +
> +config LIQUIDIO_NAPI
> + bool "Enable NAPI for LiquidIO"
> + default y
> + ---help---
> + NAPI is a new driver API designed to reduce CPU and interrupt load
> + when the driver is receiving lots of packets from the card. You
> + would only disable this feature in very specific instances, like
> + an application that very rapidly sets up and tears down connections.
> +
> + If in doubt, say Y.
You probably do not want to offer a non-NAPI variant, pretty much all
drivers have NAPI built-in now.
> +
> +config LIQUIDIO_DEBUG
> + int "Debug level for LiquidIO"
> + range 0 4
> + default 0
> + ---help---
> + Enables more extensive debug output. This may negatively
> + affect performance, so use values > 0 with caution.
> + 0 disables extra debug
> + 1 enables general messages
> + 2 enables register access messages
> + 3 enables debug messages
> + 4 enables flow messages
> +
> + If in doubt, say 0.
This should be moved to dynamic_debug/ethtools' msglvl control knob.
--
Florian
^ permalink raw reply
* Re: [PATCH v2] Add support of Cavium Liquidio ethernet adapters
From: Daniel Borkmann @ 2014-11-24 20:52 UTC (permalink / raw)
To: Raghu Vatsavayi
Cc: davem, netdev, Derek Chickles, Satanand Burla, Felix Manlunas,
Raghu Vatsavayi
In-Reply-To: <1416799190-23789-1-git-send-email-rvatsavayi@caviumnetworks.com>
On 11/24/2014 04:19 AM, Raghu Vatsavayi wrote:
> Following patch adds support for Cavium Liquidio ethernet adapter.
> LiquidIO adapters are pci express based 10Gig server adapters.
>
> Signed-off-by: Derek Chickles <derek.chickles@caviumnetworks.com>
> Signed-off-by: Satanand Burla <satananda.burla@caviumnetworks.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@caviumnetworks.com>
> Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
Please implement BQL in your 10G driver.
Additionally, you might want to consider xmit_more on top of BQL.
If you don't know what BQL is, have a look at the intro here:
http://lwn.net/Articles/454390/
^ permalink raw reply
* Re: [RFC PATCH 0/4] switch device: offload policy attributes
From: Scott Feldman @ 2014-11-24 20:48 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john.fastabend, stephen, John Linville, nhorman,
Nicolas Dichtel, vyasevic, Florian Fainelli, buytenh, Aviad Raveh,
Netdev, David S. Miller, shrijeet, Andy Gospodarek
In-Reply-To: <547346EB.7060302@cumulusnetworks.com>
On Mon, Nov 24, 2014 at 4:55 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 11/24/14, 2:18 AM, Scott Feldman wrote:
>>
>> Hi Roopa,
>>
>> I have a patch pending against Jiri's v2 that's uses existing
>> ndo_bridge_setlink/getlink to push policy settings down to port driver
>> for controlling HW offload. I had to make a few tweaks, but for the
>> most part setlink/getlink already has the master/self semantics so
>> users can set policy flags on bridge's SW version of the port (master)
>> or on the offloaded version of the port (self).
>> I added the new
>> hwmode option "swdev" to the existing "vepa"|"veb" choices. When you
>> specify hwmode, SELF is set and the port driver's setlink get's
>> called. Did you look at setlink/getlink? It looks like the kernel
>> and iproute2 where going down this route of using setlink/getlink for
>> SELF policy, so I'm wondering if we need more?
>
> If i understand you correctly, this will mean the port driver implements the
> setlink/getlink with the bridge port flags and attributes. And, it also
> means
> the port driver will parse the netlink msg instead of the bridge driver
> parsing all attributes and then calling offloads.
Yes, exactly, the port driver parses/fills bridge_setlink/getlink
netlink msg to set/get port settings. It's basically a passthru for
rtnl_bridge_setlink/getlink handling RTM_GETLNK/RTM_SETLINK on
PF_BRIDGE.
> But, in cases where we want bridge port flags and attributes set both in hw
> and sw,
> the user (iproute2) will have to set both MASTER and SELF flags, and the
> netlink parsing will now happen in two places, the bridge driver and the
> bridge port
> driver ?
Yes, that's correct. That seems to be the intent of the current
design based on the existing code. I had to do minor changes to get
brport flags passed back up in getlink, but for the most part the
kernel code and iproute2 code where already setup to support this dual
master/self model. As an example, let's consider the flags
IFLA_BRPORT_LEARNING. User can set learning on/off on bridge's port
(master) and can independently set learning on/off on port driver
(self) in HW. So for typical swdev setups, the port driver would
default to learning ON and the bridge would default to learning ON.
The user would probably want to turn learning OFF on the bridge, but
all combinations of ON/OFF are available. A better example is
IFLA_BRPORT_FLOOD. If we had a single flag that applied to both
master and self, we'd run into trouble in the flooding ON case. We
don't want both the HW and bridge driver flooding as this would result
in duplicate egress pkts. If we turn flooding OFF, then neither HW or
SW flood and our bridge is broken. So we want SW bridge (master)
flooding OFF and port driver (self) have flooding ON, for the
optimized HW-offload case.
> For bridge stp state updates, the bridge driver will call the ports->setlink
> ndo op ?
No, we added a new ndo op to communicate STP state changes to port
driver. STP state transitions don't really fit into the
setlink/getlink model, although you reminded me there was a request
for a policy flag to turn STP pushes down to port driver ON/OFF.
> (We should probably rename the ndo_bridge_setlink to ndo_setlink)
The name seems correct as they're specific to RTM_GETLNK/SETLNK for PF_BRIDGE.
>>
>> On FDB entries, using master/self semantics that exist, it's clear
>> which are owned by offloaded device and which are owned by bridge.
>> The one missing annotation was a flag indicating FDB entry in bridge
>> was synced from device. And a policy flag to turn on/off syncing from
>> the device. The policy flag is just another IFLA_BRPORT flags passed
>> with setlink/getlink.
>>
>> The setlink/getlink patch will go out in v3 once I finish testing it
>> and push it to Jiri. Hopefully tomorrow.
>
>
> In my patches, I used newlink..., but in most cases all attributes set via
> newlink can be
> used with setlink and hence getlink. So, i think we are close here.
>
> But, Oh wait, i am talking about rtnl_link_ops
> ->newlink/changelink/getlink/dellink. I did not
> realize there was a parallel ndo op to this. But thats probably because,
> rtnl_link_ops can be
> used only for logical devices. But, i see bridge driver implementing both
> the
> rtnl_link_ops changelink and ndo op setlink. hmm..seems like a lot of
> duplication.
> Will look closely some more.
>
>
> Coming back to my series, i was trying to get a common set of flags for all
> netdevs
> (bridge, bond, vxlans so far), and hence the common flag in 'struct
> ifiinfomsg'.
>
> But, I am all for using existing infrastructure if it fits well.
Jiri updated his net-next-rocker tree with my latest but hasn't pushed
out v3 yet. You can see for bridging at least we now have the policy
flag support for master/self without much heavy lifting in kernel or
iproute2 code. It seems like the right move at this time, with low
chance of regressions or breaking backward compat.
> For the fdb offloads, the NTF_SELF and NTF_MASTER is in 'struct
> ndmsg->ndm_flags', which is also
> what i was proposing. So, ack there.
Ya, for FDB, the master/self model works slick and support is already
there so we should use it.
> For the bridge netdev, using the flag in IFLA_BRIDGE_FLAGS, is also ok.
Agreed.
> I will look at your patches when they are out.
v3 is imminent. You can pull net-next-rocker now to look it over.
-scott
^ permalink raw reply
* Re: [PATCH net-next v4] ipvlan: Initial check-in of the IPVLAN driver.
From: David Miller @ 2014-11-24 20:29 UTC (permalink / raw)
To: maheshb; +Cc: netdev, edumazet, maze, chavey, thockin, brandon.philips, xemul
In-Reply-To: <1416812866-13401-1-git-send-email-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Sun, 23 Nov 2014 23:07:46 -0800
> This driver is very similar to the macvlan driver except that it
> uses L3 on the frame to determine the logical interface while
> functioning as packet dispatcher. It inherits L2 of the master
> device hence the packets on wire will have the same L2 for all
> the packets originating from all virtual devices off of the same
> master device.
>
> This driver was developed keeping the namespace use-case in
> mind. Hence most of the examples given here take that as the
> base setup where main-device belongs to the default-ns and
> virtual devices are assigned to the additional namespaces.
...
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 26/41] vhost: virtio 1.0 endian-ness support
From: Michael S. Tsirkin @ 2014-11-24 20:28 UTC (permalink / raw)
To: Cedric Le Goater
Cc: kvm, rusty, netdev, linux-kernel, virtualization, pbonzini,
David Miller
In-Reply-To: <5473408A.2090308@fr.ibm.com>
On Mon, Nov 24, 2014 at 03:28:26PM +0100, Cedric Le Goater wrote:
> Hi Michael,
>
> Do you have a tree from where I could pull these patches ?
>
> Thanks,
>
> C.
Yes - vhost-next that linux-next includes.
--
MST
^ permalink raw reply
* Re: [PATCH] 8139too: The maximum MTU should allow for VLAN headers
From: David Miller @ 2014-11-24 20:27 UTC (permalink / raw)
To: albeu; +Cc: netdev, ben, ebiederm, bhelgaas, benoit.taine, linux-kernel
In-Reply-To: <1416744476-7372-1-git-send-email-albeu@free.fr>
From: Alban Bedel <albeu@free.fr>
Date: Sun, 23 Nov 2014 13:07:54 +0100
> As pointed out by Ben Hutchings drivers that allow using VLAN have to
> provide enough headroom for the VLAN tags.
>
> Signed-off-by: Alban Bedel <albeu@free.fr>
Applied to net-next, but I shouldn't have to guess around about what
tree your patch is for.
In the future you must specify explicitly what tree your patch is
targetted at by saying either "[PATCH net] " or "[PATCH net-next] "
in your subject line.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: fec: init maximum receive buffer size for ring1 and ring2
From: David Miller @ 2014-11-24 20:22 UTC (permalink / raw)
To: b38611; +Cc: netdev, bhutchings, stephen, festevam
In-Reply-To: <1416734586-26634-1-git-send-email-b38611@freescale.com>
From: Fugang Duan <b38611@freescale.com>
Date: Sun, 23 Nov 2014 17:23:06 +0800
> i.MX6SX fec support three rx ring1, the current driver lost to init
> ring1 and ring2 maximum receive buffer size, that cause receving
> frame date length error. The driver reports "rcv is not +last" error
> log in user case.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
This patch does not apply to the 'net' tree, although it does
apply cleanly to the net-next tree.
Determining which tree a patch is for is not my job, it is your's.
Therefore you must always explicitly state what tree your patch
is intended to be added to, by starting your Subject line
with "[PATCH net] " or "[PATCH net-next] ".
I've applied this, but next time I will just ask you to properly
submit the patch instead.
^ permalink raw reply
* Re: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
From: Greg KH @ 2014-11-24 20:22 UTC (permalink / raw)
To: josh
Cc: Pieter Smith, Richard Weinberger, Michael S. Tsirkin,
Bertrand Jacquin, Oleg Nesterov, J. Bruce Fields, Eric Dumazet,
蔡正龙, Jeff Layton, Tom Herbert,
Alexei Starovoitov, Miklos Szeredi, Peter Foley, Hugh Dickins,
Xiao Guangrong, Geert Uytterhoeven, Mel Gorman, Matt Turner,
Paul E. McKenney, Alexander Duyck, open list:FUSE: FILESYSTEM...
In-Reply-To: <20141124201450.GA18776@cloud>
On Mon, Nov 24, 2014 at 12:14:50PM -0800, josh@joshtriplett.org wrote:
> > I would, again, argue that stuff like __splice_p() not be implemented at
> > all please. It will only cause a huge proliferation of stuff like this
> > that will not make any sense, and only cause a trivial, if any, amount
> > of code savings.
> >
> > I thought you were going to not do this type of thing until you got the
> > gcc optimizer working for function callbacks.
>
> Compared to the previous patchset, there are now only two instances of
> ifdefs outside of the splice code for this, and this is one of them. In
> this case, the issue is no longer about making the code for this
> splice_read function disappear, but rather to eliminate a reference to a
> bit of splice functionality (used *inside* the FUSE splice code) that
> will not work without SPLICE_SYSCALL.
>
> Would you prefer to see this specific case handled via an #ifdef in
> fs/fuse/dev.c rather than introducing a __splice_p that people might be
> inclined to propagate? That'd be fine; the code could simply wrap
> fuse_dev_splice_read in an #ifdef and have the #else define a NULL
> fuse_dev_splice_read.
Yes, I would prefer that, but I'm not the fuse maintainer.
thanks,
greg k-h
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Eric Dumazet @ 2014-11-24 20:21 UTC (permalink / raw)
To: Josh Clark; +Cc: Dave Taht, netdev
In-Reply-To: <CAHmvzZTF76DwdyBF9og2v9Vumx5v0BhHR584uX54o5R+T+iUMw@mail.gmail.com>
On Mon, 2014-11-24 at 14:14 -0500, Josh Clark wrote:
> At the moment, I'm using standard RED (from /net/sched/sch_red.c) with
> some printks to output qstats.
printk are slowing down the kernel and might interfere with normal
behavior. Don't use them.
> Are you saying that when I set this up, I need to use the -s flag in
> tc to maintain those statistics?
stats are maintained by the kernel no matter what.
tc -s qdisc actually display them.
For instance, red_dump() copies the backlog from child qdisc.
static int red_dump(struct Qdisc *sch, struct sk_buff *skb)
{
...
sch->qstats.backlog = q->qdisc->qstats.backlog;
...
}
This backlog is probably not 0 !
^ permalink raw reply
* Re: qstats update in packet scheduling
From: Eric Dumazet @ 2014-11-24 20:20 UTC (permalink / raw)
To: Dave Taht; +Cc: Josh Clark, netdev
In-Reply-To: <CAA93jw4URTCK_O5mrJB14qAraubqj4Y-pvWMFX7ts=BWSgd-Og@mail.gmail.com>
On Mon, 2014-11-24 at 11:01 -0800, Dave Taht wrote:
> On Mon, Nov 24, 2014 at 10:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Mon, 2014-11-24 at 13:17 -0500, Josh Clark wrote:
> >
> >> But I'm seeing no change at all in qlen. qlen and backlog are both
> >> zero, which results in zero qavg, meaning I can't test the RED
> >> functionality at all.
> >
> > Wait. If you use some kernel patch without giving it, I can not comment.
> >
> > If you use regular "tc -s qdisc ...", then you'll see non zero qlen
>
> Well, assuming you have BQL or a software rate limiter in place in
> front of it...
Hardly a matter, if you send _steady_ 12Mbit on a 10Mbit link, the
bottleneck should land on RED, BQL or not.
^ permalink raw reply
* Re: [PATCH v2 net-net 0/4] Increase the limit of tuntap queues
From: David Miller @ 2014-11-24 20:15 UTC (permalink / raw)
To: pagupta
Cc: linux-kernel, netdev, jasowang, dgibson, vfalico, edumazet,
vyasevic, hkchu, xemul, therbert, bhutchings, xii, stephen, jiri,
sergei.shtylyov
In-Reply-To: <1416854006-10041-1-git-send-email-pagupta@redhat.com>
Your header message says "0/4" as if there will be 4 patches, but then
you posted a 3 patch series.
^ 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