* Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure
From: Shmulik Ladkani @ 2013-01-11 13:53 UTC (permalink / raw)
To: vyasevic, Stephen Hemminger; +Cc: netdev, davem, stephen, bridge, mst
In-Reply-To: <50EF6759.2000908@redhat.com>
Hi,
On Thu, 10 Jan 2013 20:14:01 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
> On 01/10/2013 05:10 PM, Stephen Hemminger wrote:
> > Also the concept of different filters for egress vs ingress is feature
> > madness. It doesn't make sense to have half-duplex connectivity.
>
> I am of the same opinion, but it actually simplified the code quite a
> bit, but at the cost of additional memory footprint. If you find this
> very objectionable, I can easily remove it.
Haven't looked on the V5 series yet, but just to clarify:
There's *no* different membership _filter_ for egress vs ingress.
The vlan's membership map is consulted on both ingress and egress.
However, upon egress, a vlan egress _policy_ should be applied, which
determines whether the frame should egress tagged/untagged on the egress
port.
The expected logic in detailed in [1] (please read "steps 1..5").
and the data structures needed are:
- per port: PVID
- per VLAN: port membership map
- per VLAN: port egress policy map
Altough on 1st look it might look mad ;-)
But, this is genuinely simple, highly configurable and allows great
flexibility (IMO with no additional code complexity; Vlad can probably
comment).
The motivation is to be aligned with behavior and configurability of
vlan switches.
Regards,
Shmulik
[1]
http://marc.info/?l=linux-netdev&m=135603447030826&w=2
^ permalink raw reply
* Re: [PATCH/RFC] ipv6: fib: Drop cached routes with dead neighbours on fib GC
From: Hannes Frederic Sowa @ 2013-01-11 14:01 UTC (permalink / raw)
To: Roland Dreier, David S. Miller, netdev, Roland Dreier
In-Reply-To: <20130111134058.GB8436@order.stressinduktion.org>
On Fri, Jan 11, 2013 at 02:40:58PM +0100, Hannes Frederic Sowa wrote:
> On Wed, Jan 09, 2013 at 09:44:19AM -0800, Roland Dreier wrote:
> > From: Roland Dreier <roland@purestorage.com>
> >
> > This patch is as much bug report as it is a proposal to merge this
> > specific patch. The problem is definitely real; we hit it in a
> > situation where we have two systems connected back-to-back with two
> > bonded links between them, one system reboots, and the other system
> > gets NETDEV_CHANGEADDR. This patch definitely fixes that case for us,
> > but I'm not sure it's the right place to fix this, or if it covers all
> > the cases where this could happen. Anyway...
>
> Great analysis, thanks!
>
> There is bug report which indicates a fix to this problem could
> also solve some other corner cases regarding neighbour discovery:
> https://bugzilla.kernel.org/show_bug.cgi?id=42991
The report I meant was actually not referred in this bug report:
http://article.gmane.org/gmane.linux.network/224832
ENETDOWN was also observed via bridges.
^ permalink raw reply
* Re: [PATCH 1/2] tuntap: forbid calling TUNSETIFF when detached
From: Stefan Hajnoczi @ 2013-01-11 14:42 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, mst, netdev, linux-kernel
In-Reply-To: <1357894242-25020-1-git-send-email-jasowang@redhat.com>
On Fri, Jan 11, 2013 at 04:50:41PM +0800, Jason Wang wrote:
> @@ -1546,6 +1544,9 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> struct net_device *dev;
> int err;
>
> + if (rcu_dereference_protected(tfile->detached, lockdep_rtnl_is_held()))
> + return -EINVAL;
> +
How come none of the other tfile->detached users call rcu_*()?
Stefan
^ permalink raw reply
* Re: [RFC PATCH 0/2] make mac programming for virtio net more robust
From: John Fastabend @ 2013-01-11 14:52 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, netdev, qemu-devel, virtualization, David Miller
In-Reply-To: <20130111074624.GB13315@redhat.com>
On 1/10/2013 11:46 PM, Michael S. Tsirkin wrote:
> On Fri, Jan 11, 2013 at 12:53:07PM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>>
>>> On Thu, Jan 10, 2013 at 10:45:39PM +0800, akong@redhat.com wrote:
>>>> From: Amos Kong <akong@redhat.com>
>>>>
>>>> Currenly mac is programmed byte by byte. This means that we
>>>> have an intermediate step where mac is wrong.
>>>>
>>>> Second patch introduced a new vq control command to set mac
>>>> address in one time.
>>>
>>> As you mention we could alternatively do it without
>>> new commands, simply add a feature bit that says that MACs are
>>> in the mac table.
>>> This would be a much bigger patch, and I'm fine with either way.
>>> Rusty what do you think?
>>
>> Hmm, mac filtering and "my mac address" are not quite the same thing. I
>> don't know if it matters for anyone: does it?
>> The mac address is abused
>> for things like identifying machines, etc.
>
> I don't know either. I think net core differentiates between mac and
> uc_list because linux has to know which mac to use when building
> up packets, so at some level, I agree it might be useful to identify the
> machine.
>
> BTW netdev/davem should have been copied on this, Amos I think it's a
> good idea to remember to do it next time you post.
>
>>
>> If we keep it as a separate concept, Amos' patch seems to make sense.
>
> Yes. It also keeps the patch small, I just thought I'd mention the
> option.
>
>>
>> Cheers,
>> Rusty.
>
Don't have the entire context here but if you implement the
ndo_fdb_dump() probably hooking it up to ndo_dflt_fdb_dump() you could
use the 'bridge' tool dump the uc_list.
Then use ndo_fdb_add() and ndo_fdb_del() to add and remove entries
from the uc_list. We do this today in macvlan and the ixgbe driver when
it is in SR-IOV mode and the embedded switch needs to be programmed.
fdb is "forwarding database" its a bit different then mac filtering
in that its telling the "switch" how to forward mac addresses, in
ixgbe and macvlan at least we have been overloading it a bit to also
stop filtering the mac address. I think this makes sense if you setup
forwarding to a port it doesn't make much sense to then drop them.
Maybe its not entirely applicable here just thought I would mention it.
Thanks,
John
^ permalink raw reply
* Re: [PATCH 1/2] tuntap: forbid calling TUNSETIFF when detached
From: Eric Dumazet @ 2013-01-11 14:55 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, mst, netdev, linux-kernel, Stefan Hajnoczi
In-Reply-To: <1357894242-25020-1-git-send-email-jasowang@redhat.com>
On Fri, 2013-01-11 at 16:50 +0800, Jason Wang wrote:
>
> + if (rcu_dereference_protected(tfile->detached, lockdep_rtnl_is_held()))
> + return -EINVAL;
> +
Thats an open coded rtnl_dereference()
(please cleanup the whole tun.c file)
^ permalink raw reply
* Re: Problem with IPv6 Route Cache
From: Hannes Frederic Sowa @ 2013-01-11 15:06 UTC (permalink / raw)
To: Roman Mamedov; +Cc: netdev
In-Reply-To: <20130111185126.56cababe@natsu>
On Fri, Jan 11, 2013 at 06:51:26PM +0600, Roman Mamedov wrote:
> This is on kernel version 3.7.1 inside a Xen VPS (if this matters).
>
> Can anyone advice how to deal with this problem?
> Can I disable/remove the IPv6 route cache?
> I know the IPv4 route cache was recently removed from the kernel.
There is no IPv6 route cache as there was one for IPv4. The routes are
"merely" cloned directly into the fib tree.
^ permalink raw reply
* [PATCH] cpsw: Add support to read cpu MAC address
From: Michal Bachraty @ 2013-01-11 15:15 UTC (permalink / raw)
To: grant.likely, rob.herring, rob, linux
Cc: Michal Bachraty, linux-doc, netdev, devicetree-discuss,
linux-kernel, linux-arm-kernel
Signed-off-by: Michal Bachraty <michal.bachraty@streamunlimited.com>
---
Documentation/devicetree/bindings/net/cpsw.txt | 10 +-
arch/arm/boot/dts/am33xx.dtsi | 5 +-
drivers/net/ethernet/ti/cpsw.c | 121 +++++++++++++++++++++---
include/linux/platform_data/cpsw.h | 8 ++
4 files changed, 128 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index dcaabe9..432122c 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -4,7 +4,7 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
Required properties:
- compatible : Should be "ti,cpsw"
- reg : physical base address and size of the cpsw
- registers map
+ registers map and mac-address cpu config registers
- interrupts : property with a value describing the interrupt
number
- interrupt-parent : The parent interrupt controller
@@ -25,17 +25,23 @@ Required properties:
- slave_reg_ofs : Specifies slave register offset
- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
-- mac-address : Specifies slave MAC address
Optional properties:
- ti,hwmods : Must be "cpgmac0"
- no_bd_ram : Must be 0 or 1
+- mac-address-source : Specifies source of MAC address ("user-defined-mac",
+ "cpu-id0-mac", "cpu-id01-mac", "random-mac"). If not
+ specified, "cpu-id0-mac" is selected
+- mac-address : Specifies slave MAC address for "user-defined-mac"
+ property value. When MAC address is not correct,
+ "cpu-id01-mac" is selected
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
+As default, MAC address is set from CPU (MAC_ID0 register)
Examples:
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 47fb059..f4845a3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -307,7 +307,8 @@
slaves = <1>;
reg = <0x4a100000 0x800
0x4a101200 0x100
- 0x4a101000 0x100>;
+ 0x4a101000 0x100
+ 0x44e10630 0x0C>;
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
@@ -317,7 +318,7 @@
cpsw_emac0: slave@0 {
slave_reg_ofs = <0x208>;
sliver_reg_ofs = <0xd80>;
- mac-address = [ 00 00 00 00 00 00 ];
+ mac-address-source = "cpu-id0-mac";
};
davinci_mdio: mdio@4a101000 {
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index fb1a692..b777116 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -184,6 +184,13 @@ struct cpsw_sliver_regs {
u32 rx_pri_map;
};
+struct config_regs {
+ u32 mac_id0_lo;
+ u32 mac_id0_hi;
+ u32 mac_id1_lo;
+ u32 mac_id1_hi;
+};
+
struct cpsw_slave {
struct cpsw_slave_regs __iomem *regs;
struct cpsw_sliver_regs __iomem *sliver;
@@ -199,12 +206,14 @@ struct cpsw_priv {
struct net_device *ndev;
struct resource *cpsw_res;
struct resource *cpsw_ss_res;
+ struct resource *conf_res;
struct napi_struct napi;
struct device *dev;
struct cpsw_platform_data data;
struct cpsw_regs __iomem *regs;
struct cpsw_ss_regs __iomem *ss_regs;
struct cpsw_host_regs __iomem *host_port_regs;
+ struct config_regs __iomem *conf_regs;
u32 msg_enable;
struct net_device_stats stats;
int rx_packet_max;
@@ -363,6 +372,20 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
__raw_writel(mac_lo(priv->mac_addr), &slave->regs->sa_lo);
}
+static void cpsw_get_cpu_id0_mac(struct cpsw_priv *priv)
+{
+ *((u32 *)priv->mac_addr) = __raw_readl(&priv->conf_regs->mac_id0_hi);
+ *((u16 *)(priv->mac_addr + 4)) = __raw_readw(
+ &priv->conf_regs->mac_id0_lo);
+}
+
+static void cpsw_get_cpu_id1_mac(struct cpsw_priv *priv)
+{
+ *((u32 *)priv->mac_addr) = __raw_readl(&priv->conf_regs->mac_id1_hi);
+ *((u16 *)(priv->mac_addr + 4)) = __raw_readw(
+ &priv->conf_regs->mac_id1_lo);
+}
+
static void _cpsw_adjust_link(struct cpsw_slave *slave,
struct cpsw_priv *priv, bool *link)
{
@@ -831,6 +854,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
struct cpsw_slave_data *slave_data = data->slave_data + i;
const char *phy_id = NULL;
const void *mac_addr = NULL;
+ const char *source_mac;
if (of_property_read_string(slave_node, "phy_id", &phy_id)) {
pr_err("Missing slave[%d] phy_id property\n", i);
@@ -855,9 +879,39 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
slave_data->sliver_reg_ofs = prop;
+ /* set default mac address to CPU_ID0_MAC */
+ slave_data->mac_addr_source = CPU_ID0_MAC;
+
mac_addr = of_get_mac_address(slave_node);
- if (mac_addr)
- memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
+ if (mac_addr) {
+ if (is_valid_ether_addr(mac_addr)) {
+ slave_data->mac_addr_source = USER_DEFINED_MAC;
+ memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
+ } else {
+ pr_info("Bad user defined MACID.Using CPU "\
+ "MACID0\n");
+ }
+ }
+
+ source_mac = of_get_property(slave_node, "mac-address-source",
+ NULL);
+
+ if (source_mac) {
+ if (!strcmp(source_mac, "user-defined-mac"))
+ slave_data->mac_addr_source = USER_DEFINED_MAC;
+ else if (!strcmp(source_mac, "cpu-id0-mac"))
+ slave_data->mac_addr_source = CPU_ID0_MAC;
+ else if (!strcmp(source_mac, "cpu-id1-mac"))
+ slave_data->mac_addr_source = CPU_ID1_MAC;
+ else if (!strcmp(source_mac, "random-mac"))
+ slave_data->mac_addr_source = RANDOM_MAC;
+ else {
+ pr_err("Slave[%d] Bad mac-address-source"\
+ "proprerty value\n", i);
+ ret = -EINVAL;
+ goto error_ret;
+ }
+ }
i++;
}
@@ -915,16 +969,6 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
}
data = &priv->data;
- if (is_valid_ether_addr(data->slave_data[0].mac_addr)) {
- memcpy(priv->mac_addr, data->slave_data[0].mac_addr, ETH_ALEN);
- pr_info("Detected MACID = %pM", priv->mac_addr);
- } else {
- eth_random_addr(priv->mac_addr);
- pr_info("Random MACID = %pM", priv->mac_addr);
- }
-
- memcpy(ndev->dev_addr, priv->mac_addr, ETH_ALEN);
-
priv->slaves = kzalloc(sizeof(struct cpsw_slave) * data->slaves,
GFP_KERNEL);
if (!priv->slaves) {
@@ -986,6 +1030,54 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
}
priv->ss_regs = regs;
+ /* configuration register registering*/
+ priv->conf_res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
+ if (!priv->conf_res) {
+ dev_err(priv->dev, "error getting i/o resource\n");
+ ret = -ENOENT;
+ goto clean_clk_ret;
+ }
+
+ if (!request_mem_region(priv->conf_res->start,
+ resource_size(priv->conf_res), ndev->name)) {
+ dev_err(priv->dev, "failed request i/o region\n");
+ ret = -ENXIO;
+ goto clean_clk_ret;
+ }
+
+ regs = ioremap(priv->conf_res->start,
+ resource_size(priv->conf_res));
+ if (!regs) {
+ dev_err(priv->dev, "unable to map i/o region\n");
+ goto clean_configuration_iores_ret;
+ }
+ priv->conf_regs = regs;
+
+ switch (data->slave_data[0].mac_addr_source) {
+ case USER_DEFINED_MAC:
+ /* read MAC adddress from DT*/
+ memcpy(priv->mac_addr, data->slave_data[0].mac_addr, ETH_ALEN);
+ pr_info("User defined MACID = %pM", priv->mac_addr);
+ break;
+ case CPU_ID0_MAC:
+ /* read MAC adddress from CPU MACID0*/
+ cpsw_get_cpu_id0_mac(priv);
+ pr_info("CPU MACID0 = %pM\n", priv->mac_addr);
+ break;
+ case CPU_ID1_MAC:
+ /* read MAC adddress from CPU MACID1*/
+ cpsw_get_cpu_id1_mac(priv);
+ pr_info("CPU MACID1 = %pM\n", priv->mac_addr);
+ break;
+ case RANDOM_MAC:
+ /* random MAC*/
+ eth_random_addr(priv->mac_addr);
+ pr_info("Random MACID = %pM\n", priv->mac_addr);
+ break;
+ }
+
+ memcpy(ndev->dev_addr, priv->mac_addr, ETH_ALEN);
+
for_each_slave(priv, cpsw_slave_init, priv);
memset(&dma_params, 0, sizeof(dma_params));
@@ -1099,6 +1191,9 @@ clean_dma_ret:
cpdma_ctlr_destroy(priv->dma);
clean_iomap_ret:
iounmap(priv->regs);
+clean_configuration_iores_ret:
+ release_mem_region(priv->conf_res->start,
+ resource_size(priv->conf_res));
clean_cpsw_ss_iores_ret:
release_mem_region(priv->cpsw_ss_res->start,
resource_size(priv->cpsw_ss_res));
@@ -1133,6 +1228,8 @@ static int __devexit cpsw_remove(struct platform_device *pdev)
resource_size(priv->cpsw_res));
release_mem_region(priv->cpsw_ss_res->start,
resource_size(priv->cpsw_ss_res));
+ release_mem_region(priv->conf_res->start,
+ resource_size(priv->conf_res));
pm_runtime_disable(&pdev->dev);
clk_put(priv->clk);
kfree(priv->slaves);
diff --git a/include/linux/platform_data/cpsw.h b/include/linux/platform_data/cpsw.h
index c4e23d0..ef064b0 100644
--- a/include/linux/platform_data/cpsw.h
+++ b/include/linux/platform_data/cpsw.h
@@ -17,12 +17,20 @@
#include <linux/if_ether.h>
+enum mac_address_source {
+ USER_DEFINED_MAC = 0,
+ CPU_ID0_MAC,
+ CPU_ID1_MAC,
+ RANDOM_MAC,
+};
+
struct cpsw_slave_data {
u32 slave_reg_ofs;
u32 sliver_reg_ofs;
const char *phy_id;
int phy_if;
u8 mac_addr[ETH_ALEN];
+ enum mac_address_source mac_addr_source;
};
struct cpsw_platform_data {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure
From: Vlad Yasevich @ 2013-01-11 15:33 UTC (permalink / raw)
To: Shmulik Ladkani; +Cc: Stephen Hemminger, netdev, davem, bridge, mst
In-Reply-To: <20130111155354.4ff8aeac.shmulik.ladkani@gmail.com>
On 01/11/2013 08:53 AM, Shmulik Ladkani wrote:
> Hi,
>
> On Thu, 10 Jan 2013 20:14:01 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
>> On 01/10/2013 05:10 PM, Stephen Hemminger wrote:
>>> Also the concept of different filters for egress vs ingress is feature
>>> madness. It doesn't make sense to have half-duplex connectivity.
>>
>> I am of the same opinion, but it actually simplified the code quite a
>> bit, but at the cost of additional memory footprint. If you find this
>> very objectionable, I can easily remove it.
>
> Haven't looked on the V5 series yet, but just to clarify:
>
> There's *no* different membership _filter_ for egress vs ingress.
> The vlan's membership map is consulted on both ingress and egress.
Right.
>
> However, upon egress, a vlan egress _policy_ should be applied, which
> determines whether the frame should egress tagged/untagged on the egress
> port.
Right. This is how it is implemented in this series and this is what
Stephen finds "mad". You can configure the policy that on egress the
packet is untagged, but on ingress it has to be tagged. This kind of
half-duplex configuration is very prone to errors.
-vlad
>
> The expected logic in detailed in [1] (please read "steps 1..5").
> and the data structures needed are:
> - per port: PVID
> - per VLAN: port membership map
> - per VLAN: port egress policy map
>
> Altough on 1st look it might look mad ;-)
> But, this is genuinely simple, highly configurable and allows great
> flexibility (IMO with no additional code complexity; Vlad can probably
> comment).
>
> The motivation is to be aligned with behavior and configurability of
> vlan switches.
>
> Regards,
> Shmulik
>
> [1]
> http://marc.info/?l=linux-netdev&m=135603447030826&w=2
>
^ permalink raw reply
* R: Re: R: Re: mtu issue with ipsec tunnel and netfilter snat
From: pupilla @ 2013-01-11 15:34 UTC (permalink / raw)
To: jengelh; +Cc: netdev
jengelh@inai.de wrote
>On Thursday 2013-01-10 17:46, pupilla@libero.it wrote:
>
>>jengelh@inai.de wrote:
>>>>
>>>>But why linux_gw_snat is not sending icmp need to frag packets to
>>>>10.148.12.23?
>>>
>>>Perhaps because ICMP was blocked erroneously?
>>
>>well, I don't see the icmp packets because tcpdump 'see' only the
>>incoming ipsec clear packets. Is there a way to see the outgoing clear
>>ipsec packets with tcpdump?
>
>Not with AF_PACKET sockets (tcpdump uses such), but you could with
>iptables -j LOG, NFLOG and TRACE they can be made visible. If you need
>the full packet, you can either patch up LOG to call the kernel hexdump
>functions, or use NFLOG - I think - to deliver it to any userspace
>program to do further processing. If all else fails, there is also
>NFQUEUE with which the packet can also be copied to userspace.
>
Thanks for the reply.
I have saved the esp packets with tcpdump and then
decrypted with wireshark. Indeed, the icmp need to
frag packets are being sent by the linux ipsec
gateway.
Thanks for support.
^ permalink raw reply
* Re: [PATCH] cpsw: Add support to read cpu MAC address
From: Russell King - ARM Linux @ 2013-01-11 15:47 UTC (permalink / raw)
To: Michal Bachraty
Cc: grant.likely, rob.herring, rob, devicetree-discuss, linux-doc,
linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <1357917302-32550-1-git-send-email-michal.bachraty@streamunlimited.com>
On Fri, Jan 11, 2013 at 04:15:02PM +0100, Michal Bachraty wrote:
> + if (!request_mem_region(priv->conf_res->start,
> + resource_size(priv->conf_res), ndev->name)) {
> + dev_err(priv->dev, "failed request i/o region\n");
> + ret = -ENXIO;
> + goto clean_clk_ret;
> + }
> +
> + regs = ioremap(priv->conf_res->start,
> + resource_size(priv->conf_res));
> + if (!regs) {
> + dev_err(priv->dev, "unable to map i/o region\n");
> + goto clean_configuration_iores_ret;
> + }
In this day and age where error paths don't get any testing, and are
frequently buggy, where we have alternative APIs which make those paths
more reliable, I think we should do everything to make use of that.
And, to prove the point, your error paths are buggy. Yes, you release
the mem region correctly (well done for picking the right interface for
that!) but the ioremap() is never cleaned up.
So, any chance of converting the above to devm_request_and_ioremap() ?
Thanks.
^ permalink raw reply
* per route MTU settings
From: pupilla @ 2013-01-11 16:29 UTC (permalink / raw)
To: netdev
Hello everybody.
I have done some tests with per route
mtu settings.
Here is the results on the 10.81.104.254
linux box running 3.6.9 on Slackware 14
32bit:
ip route add 10.81.105.109/32 via 10.81.104.1 mtu lock 1450
ip route flush cache
ping -M do 10.81.105.109 -c 5 -s 1450
PING 10.81.105.109 (10.81.105.109) 1450(1478) bytes of data.
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
Here is the results on my linux box with
ip address 10.81.104.126 (the default
gateway is 10.81.104.254) running linux
3.7.0 on Slackware 14 64bit
ping -M do 10.81.105.109 -c 5 -s 560
PING 10.81.105.109 (10.81.105.109) 560(588) bytes of data.
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
When packets are generated locally (on
the 10.81.104.254 box), linux icmp message
'need to frag' report the correct mtu of
next hop. Instead on the forwarded packets
(those that aren't originated on the 10.81.104.254
box), I always get the 576 value on the mtu
of nexthop.
Is this the expected behaviour?
Any response are welcome
TIA
^ permalink raw reply
* Re: Problem with IPv6 Route Cache
From: Roman Mamedov @ 2013-01-11 16:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130111185126.56cababe@natsu>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
Hello,
I have discovered that when the problem is occuring, I have:
root@neru:~# ip -6 neigh
fd39:20::39 dev tun-rm FAILED
fe80::20b:45ff:fe80:c000 dev eth0 lladdr 00:0b:45:80:c0:00 router REACHABLE
2a02:e00:ffff:56::1 dev eth0 lladdr 00:0b:45:80:c0:00 router REACHABLE
Launching "ping6 fd39:20::39" turns fd39:20::39 from FAILED to REACHABLE.
After that, "ip -6 route flush cache" actually succeeds in removing the route
via default gateway, and I then get the proper route entry:
root@neru:~# ip -6 route get fd39::100
fd39::100 from :: via fd39:20::39 dev tun-rm src fd39:20::3 metric 0
cache
So I conclude that my issue is very similar to [1] mentioned in a Bugzilla
entry [2] linked here just today.
[1] https://lkml.org/lkml/2012/5/25/96
[2] https://bugzilla.kernel.org/show_bug.cgi?id=42991
--
With respect,
Roman
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 1/2] [iproute2] add man7 to subdirs list
From: Mike Frysinger @ 2013-01-11 16:56 UTC (permalink / raw)
To: stephen.hemminger, netdev
The man dir misses the man7 as a subdir which means none of the pages
get installed.
URL: https://bugs.gentoo.org/451166
Reported-by: Marcin Mirosław <bug@mejor.pl>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
man/Makefile | 2 +-
man/man7/Makefile | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 man/man7/Makefile
diff --git a/man/Makefile b/man/Makefile
index 67fea05..9a60fa7 100644
--- a/man/Makefile
+++ b/man/Makefile
@@ -2,7 +2,7 @@ INSTALL=install
INSTALLDIR=install -m 0755 -d
INSTALLMAN=install -m 0644
-SUBDIRS = man3 man8
+SUBDIRS = man3 man7 man8
all:
@for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir; done
diff --git a/man/man7/Makefile b/man/man7/Makefile
new file mode 100644
index 0000000..ccfd839
--- /dev/null
+++ b/man/man7/Makefile
@@ -0,0 +1,13 @@
+MAN7PAGES = tc-hfsc.7
+
+all:
+
+distclean: clean
+
+clean:
+
+install:
+ $(INSTALLDIR) $(DESTDIR)$(MANDIR)/man7
+ $(INSTALLMAN) $(MAN7PAGES) $(DESTDIR)$(MANDIR)/man7
+
+.PHONY: install clean distclean
--
1.8.0.2
^ permalink raw reply related
* [PATCH 2/2] [iproute2] do not ignore errors in man subdirs
From: Mike Frysinger @ 2013-01-11 16:56 UTC (permalink / raw)
To: stephen.hemminger, netdev
In-Reply-To: <1357923389-20114-1-git-send-email-vapier@gentoo.org>
If an error occurs in a man subdir, make sure we propagate it back up.
While we're here, merge the duplicate rules into one.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
man/Makefile | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/man/Makefile b/man/Makefile
index 9a60fa7..749faa1 100644
--- a/man/Makefile
+++ b/man/Makefile
@@ -4,17 +4,11 @@ INSTALLMAN=install -m 0644
SUBDIRS = man3 man7 man8
-all:
- @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir; done
+all clean install:
+ @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir $@ || exit $$?; done
distclean: clean
-clean:
- @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir clean; done
-
-install:
- @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir install; done
-
.PHONY: install clean distclean
.EXPORT_ALL_VARIABLES:
--
1.8.0.2
^ permalink raw reply related
* Re: [net-next 09/15] e1000e: resolve checkpatch PREFER_PR_LEVEL warning
From: Joe Perches @ 2013-01-11 17:03 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann
In-Reply-To: <1357899831-4168-10-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, 2013-01-11 at 02:23 -0800, Jeff Kirsher wrote:
> WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ...
> then pr_info(... to printk(KERN_INFO ...
[]
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
[]
> @@ -4300,9 +4300,8 @@ static void e1000_print_link_info(struct e1000_adapter *adapter)
> u32 ctrl = er32(CTRL);
>
> /* Link status message must follow this format for user tools */
> - printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",
> - adapter->netdev->name,
> - adapter->link_speed,
> + pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",
> + adapter->netdev->name, adapter->link_speed,
Don't these changes break a user-space tool?
If not, please remove the comment above the pr_info()s
and remove the unnecessary e1000e: prefixes.
> @@ -4521,8 +4520,8 @@ static void e1000_watchdog_task(struct work_struct *work)
[]
> /* Link status message must follow this format */
> - printk(KERN_INFO "e1000e: %s NIC Link is Down\n",
> - adapter->netdev->name);
> + pr_info("e1000e: %s NIC Link is Down\n",
> + adapter->netdev->name);
^ permalink raw reply
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Stephen Hemminger @ 2013-01-11 17:20 UTC (permalink / raw)
To: vyasevic; +Cc: mst, netdev, stephen, bridge, shmulik.ladkani, davem
In-Reply-To: <50EF660B.2090500@redhat.com>
What I think is the least intrusive and allows for maximum flexibility
is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
There already is drivers that depend on that value to enable filtering.
And make the support of VLAN filtering in the bridge conditional like
IGMP snooping is optional
--- a/net/bridge/Kconfig
+++ b/net/bridge/Kconfig
@@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
Say N to exclude this support and reduce the binary size.
If unsure, say Y.
+
+config BRIDGE_VLAN_FILTERING
+ bool "VLAN filtering"
+ depends on BRIDGE
+ depends on VLAN_8021Q
+ default n
+ ---help---
+ If you say Y here, then the Ethernet bridge will be able to
+ selectively filter traffic based on VLAN tag.
+
+ Say N to exclude this support and reduce the binary size.
+
+ If unsure, say Y.
^ permalink raw reply
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Vlad Yasevich @ 2013-01-11 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <20130111092004.2d55ae65@nehalam.linuxnetplumber.net>
On 01/11/2013 12:20 PM, Stephen Hemminger wrote:
> What I think is the least intrusive and allows for maximum flexibility
> is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
> There already is drivers that depend on that value to enable filtering.
>
The only thing that I see depending on CONFIG_VLAN_8021Q is
CONFIG_VLAN_8021Q_GVRP which is part of the 8021Q support.
There are currently no other drivers depending on 8021Q functionality
and vlan filtering in drivers doesn't depend on 8021Q support in
the kernel.
I admit that I've thought of having a dependency on 8021Q as it would
have allowed me to re-use a bit more code, but decided that bridge
should be able to stand on its own in this regard. 8021Q is not
necessary to turn on VLAN accelerated filtering on the nics as anyone
can do it through the ndo_vlan_rx_add_vid() call.
The reason for this patch was to make the nic vlan filter code reusable
and address Jiri Pirko's comment in the V2 series.
(http://marc.info/?l=linux-netdev&m=135590565719164&w=2). This way,
bridge wouldn't need to make direct ndo_ calls and all call sights will
be consistent.
> And make the support of VLAN filtering in the bridge conditional like
> IGMP snooping is optional
I could certainly make the VLAN filtering conditional, but I am not sure
what it would buy us other then a lot of ifdefs.
Thanks
-vlad
>
> --- a/net/bridge/Kconfig
> +++ b/net/bridge/Kconfig
> @@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
> Say N to exclude this support and reduce the binary size.
>
> If unsure, say Y.
> +
> +config BRIDGE_VLAN_FILTERING
> + bool "VLAN filtering"
> + depends on BRIDGE
> + depends on VLAN_8021Q
> + default n
> + ---help---
> + If you say Y here, then the Ethernet bridge will be able to
> + selectively filter traffic based on VLAN tag.
> +
> + Say N to exclude this support and reduce the binary size.
> +
> + If unsure, say Y.
>
^ permalink raw reply
* RE: [net-next 09/15] e1000e: resolve checkpatch PREFER_PR_LEVEL warning
From: Allan, Bruce W @ 2013-01-11 18:05 UTC (permalink / raw)
To: Joe Perches, Kirsher, Jeffrey T
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <1357923819.2327.5.camel@joe-AO722>
> -----Original Message-----
> From: Joe Perches [mailto:joe@perches.com]
> Sent: Friday, January 11, 2013 9:04 AM
> To: Kirsher, Jeffrey T
> Cc: davem@davemloft.net; Allan, Bruce W; netdev@vger.kernel.org;
> gospo@redhat.com; sassmann@redhat.com
> Subject: Re: [net-next 09/15] e1000e: resolve checkpatch PREFER_PR_LEVEL
> warning
>
> On Fri, 2013-01-11 at 02:23 -0800, Jeff Kirsher wrote:
> > WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ...
> > then pr_info(... to printk(KERN_INFO ...
> []
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> []
> > @@ -4300,9 +4300,8 @@ static void e1000_print_link_info(struct
> e1000_adapter *adapter)
> > u32 ctrl = er32(CTRL);
> >
> > /* Link status message must follow this format for user tools */
> > - printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex,
> Flow Control: %s\n",
> > - adapter->netdev->name,
> > - adapter->link_speed,
> > + pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow
> Control: %s\n",
> > + adapter->netdev->name, adapter->link_speed,
>
> Don't these changes break a user-space tool?
>
> If not, please remove the comment above the pr_info()s
> and remove the unnecessary e1000e: prefixes.
>
> > @@ -4521,8 +4520,8 @@ static void e1000_watchdog_task(struct
> work_struct *work)
> []
> > /* Link status message must follow this format */
> > - printk(KERN_INFO "e1000e: %s NIC Link is Down\n",
> > - adapter->netdev->name);
> > + pr_info("e1000e: %s NIC Link is Down\n",
> > + adapter->netdev->name);
>
Hmm, I'm not sure how that got past our testing even after I asked to check for
redundant instances of "e1000e". This patch can be dropped and I will submit an
updated one but it will still have the "must follow this format for user tools" comment
since the user tools key off of "e1000e: <iface> NIC Link is ..." text.
Thanks,
Bruce.
^ permalink raw reply
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Stephen Hemminger @ 2013-01-11 18:23 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <50F04EDC.9040309@redhat.com>
On Fri, 11 Jan 2013 12:41:48 -0500
Vlad Yasevich <vyasevic@redhat.com> wrote:
> On 01/11/2013 12:20 PM, Stephen Hemminger wrote:
> > What I think is the least intrusive and allows for maximum flexibility
> > is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
> > There already is drivers that depend on that value to enable filtering.
> >
>
> The only thing that I see depending on CONFIG_VLAN_8021Q is
> CONFIG_VLAN_8021Q_GVRP which is part of the 8021Q support.
> There are currently no other drivers depending on 8021Q functionality
> and vlan filtering in drivers doesn't depend on 8021Q support in
> the kernel.
>
> I admit that I've thought of having a dependency on 8021Q as it would
> have allowed me to re-use a bit more code, but decided that bridge
> should be able to stand on its own in this regard. 8021Q is not
> necessary to turn on VLAN accelerated filtering on the nics as anyone
> can do it through the ndo_vlan_rx_add_vid() call.
>
> The reason for this patch was to make the nic vlan filter code reusable
> and address Jiri Pirko's comment in the V2 series.
> (http://marc.info/?l=linux-netdev&m=135590565719164&w=2). This way,
> bridge wouldn't need to make direct ndo_ calls and all call sights will
> be consistent.
>
> > And make the support of VLAN filtering in the bridge conditional like
> > IGMP snooping is optional
>
> I could certainly make the VLAN filtering conditional, but I am not sure
> what it would buy us other then a lot of ifdefs.
>
> Thanks
> -vlad
>
> >
> > --- a/net/bridge/Kconfig
> > +++ b/net/bridge/Kconfig
> > @@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
> > Say N to exclude this support and reduce the binary size.
> >
> > If unsure, say Y.
> > +
> > +config BRIDGE_VLAN_FILTERING
> > + bool "VLAN filtering"
> > + depends on BRIDGE
> > + depends on VLAN_8021Q
> > + default n
> > + ---help---
> > + If you say Y here, then the Ethernet bridge will be able to
> > + selectively filter traffic based on VLAN tag.
> > +
> > + Say N to exclude this support and reduce the binary size.
> > +
> > + If unsure, say Y.
> >
>
Doing the following shows several drivers that still depend on VLAN_8021Q being
enabled to do VLAN tagging.
$ git grep -l CONFIG_VLAN_8021Q
ethernet/3com/3c59x.c
ethernet/adaptec/starfire.c
ethernet/amd/amd8111e.c
ethernet/broadcom/cnic.c
ethernet/broadcom/tg3.c
ethernet/dlink/sundance.c
ethernet/natsemi/ns83820.c
ethernet/sis/sis900.c
ethernet/sis/sis900.h
ethernet/stmicro/stmmac/common.h
^ permalink raw reply
* Re: [PATCH 0/3] ixgbe: request_firmware for configuration parameters
From: Greg KH @ 2013-01-11 18:25 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev, davem, dwmw2, jeffrey.t.kirsher, linux-kernel
In-Reply-To: <20130111020046.15463.72333.stgit@starfish.jf.intel.com>
On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
> Most networking dials and knobs can be set using ethtool, ifconfig, ip link
> commands, or sysfs entries, all of which can be driven by startup scripts
> and other configuration tools. However, they all depend on having a netdev
> already set up, and we have some low-level device functionality that needs
> to be sorted out before we start setting up MSI-x and memory allocations.
>
> In order to do early device configuration, most kernel drivers use module
> parameters whose settings can be persisted in modprobe.d config files.
> However, these can be clumsy to use and manage, difficult to specify port
> specific values in a multiport device, and are actively discouraged in
> some circles.
>
> In this patchset, the driver uses the existing request_firmware() and
> match_token() facilities to grab an ASCII config file from userspace to
> find special startup-time configuration information that needs persistence
> across reboots. The configuration strings are formed similar to the
> mount options that get passed from /etc/fstab into filesystem modules.
Ick, please don't abuse request_firmware() for this type of thing.
What's wrong with configfs? It sounds like it will fit your need, and
that is what is created for.
greg k-h
^ permalink raw reply
* RE: per route MTU settings
From: Lukas Tribus @ 2013-01-11 18:35 UTC (permalink / raw)
To: pupilla, netdev
In-Reply-To: <22271727.642511357921768466.JavaMail.defaultUser@defaultHost>
Hi,
10.81.104.254 will never transmit anything with
> ping -M do 10.81.105.109 -c 5 -s 1450
because the host already knows a 1478 Byte packet won't fit the
1450 Byte route you made towards 10.81.104.1.
You do realize that 1450 is your ICMP payload, plus ICMP header (8B)
and IP header (20B) and you are at 1478B, which exceeds your route's
MTU.
I guess 10.81.104.1 has a 576B MTU route/interface towards
10.81.105.109, and you did the first test on 10.81.104.254,
and only afterwards you tried "-s 560" from .126, so only
then the .254 host realized the transport to 10.81.104.1
is actually a 576B MTU path.
You cannot do pings with 2 different packet sizes on 2 different hosts,
and expect them to behave exactly the same.
Running from both hosts pings with:
-s 548
-s 549
-s 1422
-s 1423
and then analyzing the results will probably give us a better
idea of what actually happens.
Regards,
Lukas
----------------------------------------
> Date: Fri, 11 Jan 2013 17:29:28 +0100
> From: pupilla@libero.it
> To: netdev@vger.kernel.org
> Subject: per route MTU settings
>
> Hello everybody.
>
> I have done some tests with per route
> mtu settings.
>
> Here is the results on the 10.81.104.254
> linux box running 3.6.9 on Slackware 14
> 32bit:
>
> ip route add 10.81.105.109/32 via 10.81.104.1 mtu lock 1450
> ip route flush cache
>
> ping -M do 10.81.105.109 -c 5 -s 1450
> PING 10.81.105.109 (10.81.105.109) 1450(1478) bytes of data.
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>
> Here is the results on my linux box with
> ip address 10.81.104.126 (the default
> gateway is 10.81.104.254) running linux
> 3.7.0 on Slackware 14 64bit
>
> ping -M do 10.81.105.109 -c 5 -s 560
> PING 10.81.105.109 (10.81.105.109) 560(588) bytes of data.
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>
> When packets are generated locally (on
> the 10.81.104.254 box), linux icmp message
> 'need to frag' report the correct mtu of
> next hop. Instead on the forwarded packets
> (those that aren't originated on the 10.81.104.254
> box), I always get the 576 value on the mtu
> of nexthop.
> Is this the expected behaviour?
>
> Any response are welcome
>
> TIA
> --
> 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
* [PATCH] net: Export __netdev_pick_tx so that it can be used in modules
From: Alexander Duyck @ 2013-01-11 18:38 UTC (permalink / raw)
To: netdev; +Cc: davem
When testing with FCoE enabled we discovered that I had not exported
__netdev_pick_tx. As a result ixgbe doesn't build with the RFC patches
applied because ixgbe_select_queue was calling the function. This change
corrects that build issue by correctly exporting __netdev_pick_tx so it
can be used by modules.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/core/dev.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 95de4c0..d1e8116 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2746,6 +2746,7 @@ u16 __netdev_pick_tx(struct net_device *dev, struct sk_buff *skb)
return queue_index;
}
+EXPORT_SYMBOL(__netdev_pick_tx);
struct netdev_queue *netdev_pick_tx(struct net_device *dev,
struct sk_buff *skb)
^ permalink raw reply related
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Vlad Yasevich @ 2013-01-11 18:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <20130111102318.579abe94@nehalam.linuxnetplumber.net>
On 01/11/2013 01:23 PM, Stephen Hemminger wrote:
> On Fri, 11 Jan 2013 12:41:48 -0500
> Vlad Yasevich <vyasevic@redhat.com> wrote:
>
>> On 01/11/2013 12:20 PM, Stephen Hemminger wrote:
>>> What I think is the least intrusive and allows for maximum flexibility
>>> is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
>>> There already is drivers that depend on that value to enable filtering.
>>>
>>
>> The only thing that I see depending on CONFIG_VLAN_8021Q is
>> CONFIG_VLAN_8021Q_GVRP which is part of the 8021Q support.
>> There are currently no other drivers depending on 8021Q functionality
>> and vlan filtering in drivers doesn't depend on 8021Q support in
>> the kernel.
>>
>> I admit that I've thought of having a dependency on 8021Q as it would
>> have allowed me to re-use a bit more code, but decided that bridge
>> should be able to stand on its own in this regard. 8021Q is not
>> necessary to turn on VLAN accelerated filtering on the nics as anyone
>> can do it through the ndo_vlan_rx_add_vid() call.
>>
>> The reason for this patch was to make the nic vlan filter code reusable
>> and address Jiri Pirko's comment in the V2 series.
>> (http://marc.info/?l=linux-netdev&m=135590565719164&w=2). This way,
>> bridge wouldn't need to make direct ndo_ calls and all call sights will
>> be consistent.
>>
>>> And make the support of VLAN filtering in the bridge conditional like
>>> IGMP snooping is optional
>>
>> I could certainly make the VLAN filtering conditional, but I am not sure
>> what it would buy us other then a lot of ifdefs.
>>
>> Thanks
>> -vlad
>>
>>>
>>> --- a/net/bridge/Kconfig
>>> +++ b/net/bridge/Kconfig
>>> @@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
>>> Say N to exclude this support and reduce the binary size.
>>>
>>> If unsure, say Y.
>>> +
>>> +config BRIDGE_VLAN_FILTERING
>>> + bool "VLAN filtering"
>>> + depends on BRIDGE
>>> + depends on VLAN_8021Q
>>> + default n
>>> + ---help---
>>> + If you say Y here, then the Ethernet bridge will be able to
>>> + selectively filter traffic based on VLAN tag.
>>> +
>>> + Say N to exclude this support and reduce the binary size.
>>> +
>>> + If unsure, say Y.
>>>
>>
>
> Doing the following shows several drivers that still depend on VLAN_8021Q being
> enabled to do VLAN tagging.
> $ git grep -l CONFIG_VLAN_8021Q
> ethernet/3com/3c59x.c
> ethernet/adaptec/starfire.c
> ethernet/amd/amd8111e.c
> ethernet/broadcom/cnic.c
> ethernet/broadcom/tg3.c
> ethernet/dlink/sundance.c
> ethernet/natsemi/ns83820.c
> ethernet/sis/sis900.c
> ethernet/sis/sis900.h
> ethernet/stmicro/stmmac/common.h
OK. You've convinced me. I can make my code depend on 8021Q and move
these functions into vlan module.
I'll update the series with these changes.
-vlad
^ permalink raw reply
* Re: [PATCH] net: Export __netdev_pick_tx so that it can be used in modules
From: John Fastabend @ 2013-01-11 19:02 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, davem
In-Reply-To: <20130111183842.6152.34578.stgit@ahduyck-cp1.jf.intel.com>
On 1/11/2013 10:38 AM, Alexander Duyck wrote:
> When testing with FCoE enabled we discovered that I had not exported
> __netdev_pick_tx. As a result ixgbe doesn't build with the RFC patches
> applied because ixgbe_select_queue was calling the function. This change
> corrects that build issue by correctly exporting __netdev_pick_tx so it
> can be used by modules.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
Hi Alex,
If we get XPS to play nicely with the traffic class schemes we
can just remove select_queue completely.
I'll take a look tomorrow.
Thanks,
John
^ permalink raw reply
* Re: qmi_wwan on Huawei E398
From: Bjørn Mork @ 2013-01-11 19:27 UTC (permalink / raw)
To: Cedric Jehasse, netdev
In-Reply-To: <CABvLYuAX=r_Y0AdDtNp5g0kRYeP6suhLe_b68a7sQYJ-i7wrvg@mail.gmail.com>
Cedric Jehasse <cedric.jehasse@gmail.com> wrote:
>Hi,
>
>I'm trying to use qmi on an Huawei E398 dongle with ofono on a 3.7.1
>kernel. (this works with a 3.5.0 kernel)
>ofono looks for the class/subclass/protocol of the parent
>usb_interface device for the qmi_wwan and cdc_wdm devices. This must
>match with ff/01/08 and ff/01/09 Cls/Sub/Prot.
>
>Below is a trace of the udev events and usb-device output for a 3.5.0
>and 3.7.1 kernel. The difference is in the parent devices for wwan0
>and cdc-wdm0.
>The parent device for wwan0 is on a 3.7.1 kernel is If3. Is this
>normal?
>
>* 3.5.0:
>KERNEL[201.262240] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usb/cdc-wdm0 (usb)
>KERNEL[201.347292] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.4/net/wwan0 (net)
>
>T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
>D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>P: Vendor=12d1 ProdID=150a Rev=00.00
>S: Manufacturer=Huawei Technologies
>S: Product=HUAWEI Mobile
>S: SerialNumber=1234567890ABCDEF
>C: #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=cdc_wdm
>I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>* 3.7.1:
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>
>T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
>D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>P: Vendor=12d1 ProdID=150a Rev=00.00
>S: Manufacturer=Huawei Technologies
>S: Product=HUAWEI Mobile
>S: SerialNumber=1234567890ABCDEF
>C: #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=qmi_wwan
>I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>Thanks,
>Cedric
This looks right to me. There is a single function using two USB interfaces. We started out letting the cdc-wdm driver handle the control interface and the qmi_wwan driver the data interface. This is what you see in 3.5. But splitting a function like this was very awkward and made devices like the E398 behave differently from most other QMI devices, which only use a single USB interface.
So we changed this to let the qmi_wwan driver handle both interfaces. This is what you see in 3.7. The control interface is now the parent of both the cdc_wdm character device and the wwan network device and the data interface is just a data interface.
I realize that this is balancing on the edge of acceptable userspace visible changes, but all this did was making devices like the E398 look similar to single interface devices. Which already had to be supported by the userspace applications.
Now I understand that ofono does a lot stricter matching than I have anticipated, looking at the vendor specific subclass and protocol fields of the wwan parent interface. I don't think we can fix that without updating ofono. Sorry. If it is going to do that then it needs to accept both ff/01/08 and ff/01/09.
Bjørn
^ 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