* Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
From: Andri Yngvason @ 2015-01-23 10:32 UTC (permalink / raw)
To: Ahmed S. Darwish, Wolfgang Grandegger
Cc: Olivier Sobrie, Oliver Hartkopp, Marc Kleine-Budde, Linux-CAN,
netdev, LKML
In-Reply-To: <20150123060734.GA7949@Darwish.PC>
Quoting Ahmed S. Darwish (2015-01-23 06:07:34)
> On Wed, Jan 21, 2015 at 05:13:45PM +0100, Wolfgang Grandegger wrote:
> > On Wed, 21 Jan 2015 10:36:47 -0500, "Ahmed S. Darwish"
> > <darwish.07@gmail.com> wrote:
> > > On Wed, Jan 21, 2015 at 03:00:15PM +0000, Andri Yngvason wrote:
> > >> Quoting Ahmed S. Darwish (2015-01-21 14:43:23)
> > >> > Hi!
> > >
> > > ...
> > >
> > >> > <-- Unplug the cable -->
> > >> >
> > >> > (000.009106) can0 20000080 [8] 00 00 00 00 00 00 08 00
> > >> > ERRORFRAME
> > >> > bus-error
> > >> > error-counter-tx-rx{{8}{0}}
> > >> > (000.001872) can0 20000080 [8] 00 00 00 00 00 00 10 00
> >
> > For a bus-errors I would also expcect some more information in the
> > data[2..3] fields. But these are always zero.
> >
>
> M16C error factors made it possible to report things like
> CAN_ERR_PROT_FORM/STUFF/BIT0/BIT1/TX in data[2], and
> CAN_ERR_PROT_LOC_ACK/CRC_DEL in data[3].
>
> Unfortunately such error factors are only reported in Leaf, but
> not in USBCan-II due to the wire format change in the error event:
>
> struct leaf_msg_error_event {
> u8 tid;
> u8 flags;
> __le16 time[3];
> u8 channel;
> u8 padding;
> u8 tx_errors_count;
> u8 rx_errors_count;
> u8 status;
> u8 error_factor;
> } __packed;
>
> struct usbcan_msg_error_event {
> u8 tid;
> u8 padding;
> u8 tx_errors_count_ch0;
> u8 rx_errors_count_ch0;
> u8 tx_errors_count_ch1;
> u8 rx_errors_count_ch1;
> u8 status_ch0;
> u8 status_ch1;
> __le16 time;
> } __packed;
>
> I speculate that the wire format was changed due to controller
> bugs in the USBCan-II, which was slightly mentioned in their
> data sheets here:
>
> http://www.kvaser.com/canlib-webhelp/page_hardware_specific_can_controllers.html
>
> So it seems there's really no way for filling such bus error
> info given the very limited amount of data exported :-(
>
We experienced similar problems with FlexCAN.
>
> The issue of incomplete data does not even stop here, kindly
> check below notes regarding reverse state transitions:
>
> > >> > ERRORFRAME
> > >> > bus-error
> > >> > error-counter-tx-rx{{16}{0}}
> > >> [...]
[...]
> > >> > ERRORFRAME
> > >> > bus-error
> > >> > error-counter-tx-rx{{128}{0}}
> > >> >
> > >> > (( Then a continous flood, exactly similar to the above packet,
> > >> > appears.
> > >> > Unfortunately this flooding is a firmware problem. ))
> > >> >
> > >> > <-- Replug the cable, after a good amount of time -->
> > >> >
> > >> Where are the reverse state transitions?
> > >> >
> > >
> > > Hmmm...
> > >
> > > [ ... ]
> > >>
> > >> Reverse state transitions are missing from the logs. See comments
> > above.
> > >>
> > >
> > > When the device is on the _receiving_ end, and I unplug the CAN cable
> > after
> > > introducing some noise to the level of reaching WARNING or PASSIVE, I
> > > receive a BUS_ERROR event with the rxerr count reset back to 0 or 1. In
> > > that case, the driver correctly transitions back the state to
> > ERROR_ACTIVE
> > > and candump produces something similar to:
> > >
> > > (000.000362) can0 2000008C [8] 00 40 40 00 00 00 00 01
> > > ERRORFRAME
> > > controller-problem{}
> > > protocol-violation{{back-to-error-active}{}}
> > > bus-error
> > > error-counter-tx-rx{{0}{1}}
> > >
> > > which is, AFAIK, the correct behaviour from the driver side.
> > >
> > > Meanwhile, when the device is on the _sending_ end and I re-plug the CAN
> > > cable again. Sometimes I receive events with txerr reset to 0 or 1, and
> > > the driver correctly reverts back to ERROR_ACTIVE in that case. But on
> > > another times like the quoted case above, I don't receive any events
> > > resetting txerr back -- only data packets on the bus.
> >
> > Well, the firmware seems to report *only* bus-errors via
> > CMD_CAN_ERROR_EVENT messages, also carrying the new state, but no
> > CMD_CHIP_STATE_EVENT just for the state changes.
> >
>
> I've dumped _every_ message I receive from the firmware while
> disconnecting the CAN bus, waiting a while, and connecting it again.
> I really received _nothing_ from the firmware when the CAN bus was
> reconnected and the data packets were flowing again. Not even a
> single CHIP_STATE_EVENT, even after waiting for a long time.
>
> So it's basically:
> ...
> ERR EVENT, txerr=128, rxerr=0
> ERR EVENT, txerr=128, rxerr=0
> ERR EVENT, txerr=128, rxerr=0
> ...
>
> then complete silence, except the data frames. I've even tried with
> different versions of the firmware, but the same behaviour persisted.
>
> > > So, What can the driver do given the above?
> >
> > Little if the notification does not come.
> >
>
> We can poll the state by sending CMD_GET_CHIP_STATE to the firmware,
> and it will hopefully reply with a CHIP_STATE_EVENT response
> containing the new txerr and rxerr values that we can use for
> reverse state transitions.
>
> But do we _really_ want to go through the path? I feel that it will
> open some cans of worms w.r.t. concurrent access to both the netdev
> and USB stacks from a single driver.
>
Honestly, I don't know.
>
> A possible solution can be setting up a kernel thread that queries
> for a CHIP_STATE_EVENT every second?
>
Have you considered polling in kvaser_usb_tx_acknowledge? You could do something
like:
if(unlikely(dev->can.state != CAN_STATE_ERROR_ACTIVE))
{
request_state();
}
I don't think that anything beyond that would be worth pursuing.
Best regards,
Andri
^ permalink raw reply
* Re: [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes
From: Jiri Pirko @ 2015-01-23 10:41 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <1421987606-10884-3-git-send-email-roopa@cumulusnetworks.com>
Fri, Jan 23, 2015 at 05:33:23AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This patch adds two new api's netdev_switch_port_bridge_setlink
>and netdev_switch_port_bridge_dellink to offload bridge port attributes
>to switch asic
>
>(The names of the apis look odd with 'switch_port_bridge',
>but am more inclined to change the prefix of the api to something else.
>Will take any suggestions).
>
>The api's look at the NETIF_F_HW_NETFUNC_OFFLOAD feature flag to
>pass bridge port attributes to the port device.
>
>If the device has the NETIF_F_HW_NETFUNC_OFFLOAD, but does not support
>the bridge port attribute offload ndo, call bridge port attribute ndo's on
>the lowerdevs if supported. This is one way to pass bridge port attributes
>through stacked netdevs (example when bridge port is a bond and bond slaves
>are switch ports).
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>---
> include/net/switchdev.h | 17 ++++++++++-
> net/switchdev/switchdev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 86 insertions(+), 1 deletion(-)
>
>diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>index 8a6d164..362f53a 100644
>--- a/include/net/switchdev.h
>+++ b/include/net/switchdev.h
>@@ -17,7 +17,10 @@
> int netdev_switch_parent_id_get(struct net_device *dev,
> struct netdev_phys_item_id *psid);
> int netdev_switch_port_stp_update(struct net_device *dev, u8 state);
>-
>+int netdev_switch_port_bridge_setlink(struct net_device *dev,
>+ struct nlmsghdr *nlh, u16 flags);
>+int netdev_switch_port_bridge_dellink(struct net_device *dev,
>+ struct nlmsghdr *nlh, u16 flags);
> #else
>
> static inline int netdev_switch_parent_id_get(struct net_device *dev,
>@@ -32,6 +35,18 @@ static inline int netdev_switch_port_stp_update(struct net_device *dev,
> return -EOPNOTSUPP;
> }
>
>+int netdev_switch_port_bridge_setlink(struct net_device *dev,
>+ struct nlmsghdr *nlh, u16 flags)
>+{
>+ return -EOPNOTSUPP;
>+}
>+
>+int netdev_switch_port_bridge_dellink(struct net_device *dev,
>+ struct nlmsghdr *nlh, u16 flags)
>+{
>+ return -EOPNOTSUPP;
>+}
>+
> #endif
>
> #endif /* _LINUX_SWITCHDEV_H_ */
>diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>index d162b21..bf0be98 100644
>--- a/net/switchdev/switchdev.c
>+++ b/net/switchdev/switchdev.c
>@@ -50,3 +50,73 @@ int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
> return ops->ndo_switch_port_stp_update(dev, state);
> }
> EXPORT_SYMBOL(netdev_switch_port_stp_update);
>+
>+/**
>+ * netdev_switch_port_bridge_setlink - Notify switch device port of bridge
>+ * port attributes
>+ *
>+ * @dev: port device
>+ * @nlh: netlink msg with bridge port attributes
>+ *
>+ * Notify switch device port of bridge port attributes
>+ */
>+int netdev_switch_port_bridge_setlink(struct net_device *dev,
>+ struct nlmsghdr *nlh, u16 flags)
>+{
>+ const struct net_device_ops *ops = dev->netdev_ops;
>+ struct net_device *lower_dev;
>+ struct list_head *iter;
>+ int ret = 0, err = 0;
>+
>+ if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
>+ return err;
>+
>+ if (ops->ndo_bridge_setlink) {
>+ WARN_ON(!ops->ndo_switch_parent_id_get);
>+ return ops->ndo_bridge_setlink(dev, nlh, flags);
>+ }
>+
>+ netdev_for_each_lower_dev(dev, lower_dev, iter) {
>+ err = netdev_switch_port_bridge_setlink(lower_dev, nlh, flags);
>+ if (err)
>+ ret = err;
>+ }
>+
>+ return ret;
>+}
>+EXPORT_SYMBOL(netdev_switch_port_bridge_setlink);
>+
>+/**
>+ * netdev_switch_port_bridge_dellink - Notify switch device port of bridge
>+ * attribute delete
>+ *
>+ * @dev: port device
>+ * @nlh: netlink msg with bridge port attributes
>+ *
>+ * Notify switch device port of bridge port attribute delete
>+ */
>+int netdev_switch_port_bridge_dellink(struct net_device *dev,
>+ struct nlmsghdr *nlh, u16 flags)
>+{
>+ const struct net_device_ops *ops = dev->netdev_ops;
>+ struct net_device *lower_dev;
>+ struct list_head *iter;
>+ int ret = 0, err = 0;
>+
>+ if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD))
>+ return err;
>+
>+ if (ops->ndo_bridge_dellink) {
>+ WARN_ON(!ops->ndo_switch_parent_id_get);
>+ return ops->ndo_bridge_dellink(dev, nlh, flags);
>+ }
>+
>+ netdev_for_each_lower_dev(dev, lower_dev, iter) {
>+ err = netdev_switch_port_bridge_dellink(lower_dev, nlh, flags);
>+ if (err)
>+ ret = err;
>+ }
>+
>+ return ret;
>+}
>+EXPORT_SYMBOL(netdev_switch_port_bridge_dellink);
>--
>1.7.10.4
>
Is there any other place, other than bridge code, this functions are
suppored to be called from? If not, which I consider likely, it would
make more sense to me to:
- move netdev_for_each_lower_dev iterations directly to bridge code
- let the masters (bond, team, ..) implement ndo_bridge_*link and do
the traversing there (can be in a form of pre-prepared default
ndo callback (ndo_dflt_netdev_switch_port_bridge_*link)
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-23 10:49 UTC (permalink / raw)
To: John Fastabend
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, simon.horman, sfeldma,
netdev, davem, gerlitz.or, andy, ast, Jiri Pirko
In-Reply-To: <54C12C1F.706@gmail.com>
On 01/22/15 at 08:58am, John Fastabend wrote:
> In response to Pablo's observation,
>
> Correct this is fully exposed to user space, but it is also self
> contained inside the API meaning I can learn when to use it and what it
> does by looking at the other operations tables the table graph and
> supported headers. The assumption I am making that is not in the API
> explicitly yet. Is that actions named "set_field_name" perform the
> set operation on that field. We can and plan to extend the API to make
> this assumption explicit in the API.
OK. I think it's this assumption that is not explicitly in the API yet
that causes confusion. Making it explicit would definitely help. Do
we even need the driver to declare get/set operations at all? Can we
just have the driver expose the field and the API takes care of
providing get/set actions?
> Even though its a detail of the rocker world its easy enough for a
> program on top of the API to learn how it works.
>
> So in the rocker switch case if I want to rewrite an eth_dst adress I
> have a couple choices. I can set the group_id in one of the tables
> that support setting the group_id and then do the rewrite in one of the
> tables that supports matching on group_id and setting the eth_dst mac.
> The "choice" I make is a policy IMO and I don't want to hard code logic
> in the kernel that picks tables and decides things like what should I
> do if table x is full but table y could also be used should I overflow
> into table y? Or is table y reserved for some other network function?
> etc.
Agreed. It might make sense to declare such fields as general purpose
metadata or have some kind of field class which describes the nature
of the field: { register, protocol-field, configuration, ... }
> There are some actions and metadata though that _need_ to be
> standardized. These are the metadata that is used outside the API. For
> example ingress_port is metadata that is set outside the tables.
> Similarly set_egress_port and set_egress_queue provide the forwarding
> and queueing fields. No matter how hard you look at the model from the
> API you can not learn how these are used.
Agreed. I assume we would implement a tun_dst the same standardized way.
> >What would a rocker group map to in the tc world?
>
> In the 'tc' world I would guess the easiest thing to do is simply bind
> a 'tc' qdisc to the ACL table. It seems a good first approximation of
> how to make this work. But the rocker world doesn't yet have any QOS so
> it makes it difficult to "offload" anything but the fifo qdiscs.
Right. I was asking as tc will have the same difficulty if it wishes
to classify based on rocker groups or other general purpose hardware
metadata fields. We can either supoprt them by describing them and
allow learning of such fields or ignore them.
> >>I see this as a gaping hole
> >>for vendor SDKs with their own definitions of their own hardware that
> >>doesnt work with anyone else. i.e it seems to standardize proprietary
> >>interfaces. Maybe thats what Pablo is alluding to.
> >
> >I will be the first to root for rejection if such patches appear.
> >
>
> Is it problematic if users define some unique header here and then
> provide actions to set/pop/push/get operations on it?
I have no problem with unique headers but we have to ensure that a
field with identical purpose or same logical meaning is represented in
the same way by all drivers. If a driver introduces a new field it
must consider that other drivers will need/want to use it as well.
I guess/hope this is obvious though ;-)
I agree that if chip A has 8 general purpose registers and chip B has
32 of them then it doesn't matter how they are called. What matters is
that they are declared as such to API users.
Actions must obviously be standardized as your proposal already does
by exposing push_vlan, pop_vlan, etc.
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Mark Rutland @ 2015-01-23 10:51 UTC (permalink / raw)
To: Stathis Voukelatos
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stathis Voukelatos,
abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
In-Reply-To: <1422007621-13567-1-git-send-email-stathis.voukelatos-zgcZaY4qg+21Qrn1Bg8BZw@public.gmane.org>
On Fri, Jan 23, 2015 at 10:07:01AM +0000, Stathis Voukelatos wrote:
> This patch adds support the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-defined pattern and timestamped. It sits between a 100M
> Ethernet MAC and PHY and is completely passive with respect to
> Ethernet frames.
>
> Matched packet bytes and timestamp values are returned through a
> FIFO. Timestamps are provided to the module through an externally
> generated Gray-encoded counter.
>
> The command pattern for packet matching is stored in module RAM
> and consists of a sequence of 16-bit entries. Each entry includes
> an 8-bit command code and and 8-bit data value. Valid command
> codes are:
> 0 - Don't care
> 1 - Match: packet data must match command string byte
> 2 - Copy: packet data will be copied to FIFO
> 3 - Match/Stamp: if packet data matches string byte, a timestamp
> is copied into the FIFO
> 4 - Copy/Done: packet data will be copied into the FIFO.
> This command terminates the command string.
>
> The driver consists of two modules:
> - Core: it provides an API to user space using the Generic Netlink
> framework. Specific backend implementations, like the
> Ethernet Packet Sniffer, register one or more channels
> with the Core. For each channel a Genl family is created.
> User space can access a channel by sending Genl messages
> to the Genl family associated with the channel. Packet
> matching events are multicast.
>
> - Ethernet Packet Sniffer backend: provides the driver for the
> Linn Ethernet Packet Sniffer H/W modules.
It sounds like the framework and particular driver need to be split into
separate patches.
Also, please split the binding patch as per
Documentation/devicetree/bindings/submitting-patches.txt.
>
> The split between a core and backend modules allows software-only
> implementations to be added for platforms where no H/W support
> is available.
>
> Based on 3.19-rc5
>
> Signed-off-by: Stathis Voukelatos <stathis.voukelatos-zgcZaY4qg+21Qrn1Bg8BZw@public.gmane.org>
> ---
> .../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 +++++
> 17 files changed, 1563 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> create mode 100644 drivers/net/pkt-sniffer/Kconfig
> create mode 100644 drivers/net/pkt-sniffer/Makefile
> create mode 100644 drivers/net/pkt-sniffer/backends/ether/channel.c
> create mode 100644 drivers/net/pkt-sniffer/backends/ether/channel.h
> create mode 100644 drivers/net/pkt-sniffer/backends/ether/hw.h
> create mode 100644 drivers/net/pkt-sniffer/backends/ether/platform.c
> create mode 100644 drivers/net/pkt-sniffer/core/dev_table.c
> create mode 100644 drivers/net/pkt-sniffer/core/module.c
> create mode 100644 drivers/net/pkt-sniffer/core/nl.c
> create mode 100644 drivers/net/pkt-sniffer/core/nl.h
> create mode 100644 drivers/net/pkt-sniffer/core/snf_core.h
> create mode 100644 include/linux/pkt_sniffer.h
>
> diff --git a/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> new file mode 100644
> index 0000000..6b6e105
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> @@ -0,0 +1,27 @@
> +* Linn Products Ethernet Packet Sniffer
> +
> +Required properties:
> +- compatible : must be "linn,eth-sniffer"
> +- reg : physical addresses and sizes of registers. Must contain 3 entries:
> + first entry: registers memory space
> + second entry: TX command memory
> + third entry: RX command memory
Just to check: are those memories are part of the packet sniffer device,
or are carveouts from other memory?
> +- reg-names : must contain the following 3 entries:
> + "regs", "tx-ram", "rx-ram"
If you use reg-names, please define reg in terms of reg-names. It's a
little pointless to have redundant name and index requirements.
> +- interrupts : sniffer interrupt specifier
> +- clocks : specify the system clock for the peripheral
> +- clock-names : must contain the "sys" entry
Likewise with clocks and clock-names.
> +- fifo-block-words : number of words in one data FIFO entry
> +
> +Example:
> +
> +sniffer@1814a000 {
> + compatible = "linn,eth-sniffer";
> + reg = <0x1814a000 0x100>, <0x1814a400 0x400>, <0x1814a800 0x400>;
> + reg-names = "regs", "tx-ram", "rx-ram";
> + interrupts = <GIC_SHARED 58 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "eth-sniffer-irq";
> + clocks = <&system_clk>;
> + clock-names = "sys";
> + fifo-block-words = <4>;
> + };
Surely the relationship between the sniffer, MAC, and PHY should be
described, so we know which interface the sniffer is related to?
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index b1df0ad..2c96f35 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -90,6 +90,7 @@ lacie LaCie
> lantiq Lantiq Semiconductor
> lenovo Lenovo Group Ltd.
> lg LG Corporation
> +linn Linn Products Ltd.
> linux Linux-specific binding
> lsi LSI Corp. (LSI Logic)
> lltc Linear Technology Corporation
This addition looks fine to me.
Thanks,
Mark.
--
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: [PATCH net v2] ipv4: try to cache dst_entries which would cause a redirect
From: Hannes Frederic Sowa @ 2015-01-23 10:54 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev, Marcelo Leitner, Florian Westphal
In-Reply-To: <alpine.LFD.2.11.1501222135140.2572@ja.home.ssi.bg>
On Thu, Jan 22, 2015, at 20:57, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 22 Jan 2015, Hannes Frederic Sowa wrote:
>
> > I would try to not introduce this complexity. I am currently researching
> > if this change does improve things:
> >
> > do_cache = res->fi && !itag;
> > - if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) &&
> > - (IN_DEV_SHARED_MEDIA(out_dev) ||
> > - inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) {
> > - flags |= RTCF_DOREDIRECT;
> > - do_cache = false;
> > + if (skb->protocol == htons(ETH_P_IP)) {
> > + if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) &&
> > + skb->protocol == htons(ETH_P_IP) &&
>
> Above is duplicate. Or better to remove first
> and to keep this second check if flag is not cleared below...
Yes, noticed it too late.
>
> > + (IN_DEV_SHARED_MEDIA(out_dev) ||
> > + inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res))))
> > + IPCB(skb)->flags |= IPSKB_DOREDIRECT;
> > + else if (IPCB(skb)->flags & IPSKB_DOREDIRECT)
> > + IPCB(skb)->flags &= ~IPSKB_DOREDIRECT;
>
> It seems we do not need to clear the flag for
> ip_options_rcv_srr purposes because ip_route_input is called
> only if initial rt_type is RTN_LOCAL, so the flag should be
> unset. ip_mkroute_input/__mkroute_input is called only for
> forwarding.
Yes, that aligns pretty much with how source routing should work. :)
> In ip_options_rcv_srr we have RTN_LOCAL ... [RTN_LOCAL]
> and may be final RTN_UNICAST. The flag can be set and used
> only for RTN_UNICAST and that is the final ip_route_input
> called there. Lets keep it just with the 2nd ETH_P_IP check?
I agree, I don't see any other complications any more. Will send patch
soon. Thanks a lot! Also please feel free to add you SOB.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net 2/2] samples: bpf: relax test_maps check
From: Daniel Borkmann @ 2015-01-23 10:58 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Michael Holzheu, Martin Schwidefsky, netdev,
linux-kernel
In-Reply-To: <1421975469-13035-3-git-send-email-ast@plumgrid.com>
On 01/23/2015 02:11 AM, Alexei Starovoitov wrote:
> hash map is unordered, so get_next_key() iterator shouldn't
> rely on particular order of elements. So relax this test.
>
> Fixes: ffb65f27a155 ("bpf: add a testsuite for eBPF maps")
> Reported-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
^ permalink raw reply
* RE: [PATCH net] netxen: fix netxen_nic_poll() logic
From: Manish Chopra @ 2015-01-23 10:59 UTC (permalink / raw)
To: Eric Dumazet, Mike Galbraith, David Miller; +Cc: netdev
In-Reply-To: <1421942178.3471.10.camel@edumazet-glaptop2.roam.corp.google.com>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Thursday, January 22, 2015 9:26 PM
> To: Mike Galbraith; David Miller
> Cc: netdev; Manish Chopra
> Subject: [PATCH net] netxen: fix netxen_nic_poll() logic
>
> From: Eric Dumazet <edumazet@google.com>
>
> NAPI poll logic now enforces that a poller returns exactly the budget when it
> wants to be called again.
>
> If a driver limits TX completion, it has to return budget as well when the limit is
> hit, not the number of received packets.
>
> Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: d75b1ade567f ("net: less interrupt masking in NAPI")
> Cc: Manish Chopra <manish.chopra@qlogic.com>
> ---
> drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> index 613037584d08..c531c8ae1be4 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> @@ -2388,7 +2388,10 @@ static int netxen_nic_poll(struct napi_struct *napi,
> int budget)
>
> work_done = netxen_process_rcv_ring(sds_ring, budget);
>
> - if ((work_done < budget) && tx_complete) {
> + if (!tx_complete)
> + work_done = budget;
> +
> + if (work_done < budget) {
> napi_complete(&sds_ring->napi);
> if (test_bit(__NX_DEV_UP, &adapter->state))
> netxen_nic_enable_int(sds_ring);
>
Thanks Eric.
Acked-by: Manish Chopra <manish.chopra@qlogic.com>
^ permalink raw reply
* [PATCH net v3] ipv4: try to cache dst_entries which would cause a redirect
From: Hannes Frederic Sowa @ 2015-01-23 11:01 UTC (permalink / raw)
To: netdev; +Cc: Julian Anastasov, Marcelo Leitner, Florian Westphal
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>
---
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
^ permalink raw reply related
* [PATCH] atheros/atlx: Simplify bit manipulations
From: Rasmus Villemoes @ 2015-01-23 11:06 UTC (permalink / raw)
To: Jay Cliburn, Chris Snook; +Cc: Rasmus Villemoes, netdev, linux-kernel
The code 'if (foo & X) foo &= ~X;' is semantically equivalent to
simply 'foo &= ~X;', but gcc generates about four instructions for the
former, one for the latter. Similarly, if X consists of a single bit,
'if (!(foo & X)) X |= X;' can be replaced by 'foo |= X;'.
In the atl2 case, gcc does know how to merge the new adjacent
operations, so altogether this gives a nice little code size
reduction of about 80 bytes.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/net/ethernet/atheros/atlx/atl1.c | 3 +--
drivers/net/ethernet/atheros/atlx/atl2.c | 12 ++++--------
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c
index 2c8f398aeda9..d9d61d6e8386 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -1667,8 +1667,7 @@ static void atl1_via_workaround(struct atl1_adapter *adapter)
unsigned long value;
value = ioread16(adapter->hw.hw_addr + PCI_COMMAND);
- if (value & PCI_COMMAND_INTX_DISABLE)
- value &= ~PCI_COMMAND_INTX_DISABLE;
+ value &= ~PCI_COMMAND_INTX_DISABLE;
iowrite32(value, adapter->hw.hw_addr + PCI_COMMAND);
}
diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c b/drivers/net/ethernet/atheros/atlx/atl2.c
index 84a09e8ddd9c..46d1b959daa8 100644
--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -1278,14 +1278,10 @@ static void atl2_setup_pcicmd(struct pci_dev *pdev)
pci_read_config_word(pdev, PCI_COMMAND, &cmd);
- if (cmd & PCI_COMMAND_INTX_DISABLE)
- cmd &= ~PCI_COMMAND_INTX_DISABLE;
- if (cmd & PCI_COMMAND_IO)
- cmd &= ~PCI_COMMAND_IO;
- if (0 == (cmd & PCI_COMMAND_MEMORY))
- cmd |= PCI_COMMAND_MEMORY;
- if (0 == (cmd & PCI_COMMAND_MASTER))
- cmd |= PCI_COMMAND_MASTER;
+ cmd &= ~PCI_COMMAND_INTX_DISABLE;
+ cmd &= ~PCI_COMMAND_IO;
+ cmd |= PCI_COMMAND_MEMORY;
+ cmd |= PCI_COMMAND_MASTER;
pci_write_config_word(pdev, PCI_COMMAND, cmd);
/*
--
2.1.3
^ permalink raw reply related
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-23 11:08 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, John Fastabend, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123102421.GB2065@nanopsycho.orion>
On 01/23/15 at 11:24am, Jiri Pirko wrote:
> I think that comparing this to team or routing userspace is not
> correct. The reason is that team and routing has single api to kernel.
> However in this case userspace has to use multiple APIs.
The point I was trying to make is that there are legitimate reasons
to keep complexity out of the kernel and team is a good example for
that.
As for multiple APIs. Team does in fact export its own Generic Netlink
interface while it also hooks into rtnetlink to support ip link. Not
sure whether that qualifies for multiple APIs or not but I think it's
an excellent architecture decision. Same as for nl80211 tools.
> For example OVS. It would have to use existing OVS gennetlink iface + this
> new flow netlink iface for flow offloads. For all others, this is the same.
> Multiple apis for the same thing (does not matter if it is implemented
> in hw or sw) does not seem right to me.
Fair enough. I have no objections to merging the flow API into RTNETLINK
although I don't really see a need to put more under the rtnl umbrella
unless absolutely required.
I think John also mentioned that he proposes to have this as a separate
Generic Netlink interface for now but this could really live wherever it
seems appropriate.
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Daniel Borkmann @ 2015-01-23 11:20 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>
On 01/23/2015 11:07 AM, Stathis Voukelatos wrote:
> This patch adds support the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-defined pattern and timestamped. It sits between a 100M
> Ethernet MAC and PHY and is completely passive with respect to
> Ethernet frames.
>
> Matched packet bytes and timestamp values are returned through a
> FIFO. Timestamps are provided to the module through an externally
> generated Gray-encoded counter.
>
> The command pattern for packet matching is stored in module RAM
> and consists of a sequence of 16-bit entries. Each entry includes
> an 8-bit command code and and 8-bit data value. Valid command
> codes are:
> 0 - Don't care
> 1 - Match: packet data must match command string byte
> 2 - Copy: packet data will be copied to FIFO
> 3 - Match/Stamp: if packet data matches string byte, a timestamp
> is copied into the FIFO
> 4 - Copy/Done: packet data will be copied into the FIFO.
> This command terminates the command string.
>
> The driver consists of two modules:
> - Core: it provides an API to user space using the Generic Netlink
> framework. Specific backend implementations, like the
> Ethernet Packet Sniffer, register one or more channels
> with the Core. For each channel a Genl family is created.
> User space can access a channel by sending Genl messages
> to the Genl family associated with the channel. Packet
> matching events are multicast.
>
> - Ethernet Packet Sniffer backend: provides the driver for the
> Linn Ethernet Packet Sniffer H/W modules.
>
> The split between a core and backend modules allows software-only
> implementations to be added for platforms where no H/W support
> is available.
>
> Based on 3.19-rc5
>
> Signed-off-by: Stathis Voukelatos <stathis.voukelatos-zgcZaY4qg+21Qrn1Bg8BZw@public.gmane.org>
Please have a look at packet sockets, they offer already all the
functionality (if not more) your driver interface to the user space
resembles, are transparent to the underlying hardware, and easily
can cope with 100Mbit.
If I understand this correctly, you are effectively introducing a
parallel API *next* to packet sockets to user space that we have to
maintain forever ...
Thanks !
--
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: [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes
From: Rosen, Rami @ 2015-01-23 11:24 UTC (permalink / raw)
To: roopa@cumulusnetworks.com, jiri@resnulli.us, sfeldma@gmail.com,
jhs@mojatatu.com, bcrl@kvack.org, tgraf@suug.ch,
john.fastabend@gmail.com, stephen@networkplumber.org,
vyasevic@redhat.com, Arad, Ronen
Cc: netdev@vger.kernel.org, davem@davemloft.net,
shm@cumulusnetworks.com, gospo@cumulusnetworks.com
In-Reply-To: <1421987606-10884-3-git-send-email-roopa@cumulusnetworks.com>
Hi,
Some trivial comments:
+
+/**
+ * netdev_switch_port_bridge_setlink - Notify switch device port of bridge
+ * port attributes
+ *
+ * @dev: port device
+ * @nlh: netlink msg with bridge port attributes
+ *
+ * Notify switch device port of bridge port attributes
+ */
+int netdev_switch_port_bridge_setlink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags) {
- Missing @flags after @nlh above.
- Wouldn't "Notify switch device port of setting bridge port attributes" or "Notify switch device port of bridge port attributes set" be
better here (also in terms of being consistent with the description of the netdev_switch_port_bridge_dellink() method later in this patch)?
+/**
+ * netdev_switch_port_bridge_dellink - Notify switch device port of bridge
+ * attribute delete
+ *
+ * @dev: port device
+ * @nlh: netlink msg with bridge port attributes
+ *
+ * Notify switch device port of bridge port attribute delete
+ */
+int netdev_switch_port_bridge_dellink(struct net_device *dev,
+ struct nlmsghdr *nlh, u16 flags) {
- Again, missing @flags after @nlh for this method also.
Rami Rosen
Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 11:39 UTC (permalink / raw)
To: Thomas Graf
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, John Fastabend, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123110821.GH25797@casper.infradead.org>
Fri, Jan 23, 2015 at 12:08:21PM CET, tgraf@suug.ch wrote:
>On 01/23/15 at 11:24am, Jiri Pirko wrote:
>> I think that comparing this to team or routing userspace is not
>> correct. The reason is that team and routing has single api to kernel.
>> However in this case userspace has to use multiple APIs.
>
>The point I was trying to make is that there are legitimate reasons
>to keep complexity out of the kernel and team is a good example for
>that.
>
>As for multiple APIs. Team does in fact export its own Generic Netlink
>interface while it also hooks into rtnetlink to support ip link. Not
>sure whether that qualifies for multiple APIs or not but I think it's
>an excellent architecture decision. Same as for nl80211 tools.
Team uses multiple api for sure, but for different things.
>
>> For example OVS. It would have to use existing OVS gennetlink iface + this
>> new flow netlink iface for flow offloads. For all others, this is the same.
>> Multiple apis for the same thing (does not matter if it is implemented
>> in hw or sw) does not seem right to me.
>
>Fair enough. I have no objections to merging the flow API into RTNETLINK
>although I don't really see a need to put more under the rtnl umbrella
>unless absolutely required.
>
>I think John also mentioned that he proposes to have this as a separate
>Generic Netlink interface for now but this could really live wherever it
>seems appropriate.
Maybe I did not express myself correctly. I do not care if this is
exposed by rtnl or a separate genetlink. The issue still stands. And the
issue is that the user have to use "the way A" to setup sw datapath and
"the way B" to setup hw datapath. The preferable would be to have
"the way X" which can be used to setup both sw and hw.
And I believe that could be achieved. Consider something like this:
- have cls_xflows tc classifier and act_xflows tc action as a wrapper
(or api) for John's work. With possibility for multiple backends. The
backend iface would looke very similar to what John has now.
- other tc clses and acts will implement xflows backend
- openvswitch datapath will implement xflows backend
- rocker switch will implement xflows backend
- other drivers will implement xflows backend
Now if user wants to manipulate with any flow setting, he can just use
cls_xflows and act_xflows to to that.
This is very rough, but I just wanted to draw the picture. This would
provide single entry to flow world manipulation in kernel, no matter if
sw or hw.
Thoughts?
^ permalink raw reply
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Daniel Borkmann @ 2015-01-23 11:50 UTC (permalink / raw)
To: Sun Paul; +Cc: linux-sctp, netdev, linux-kernel, vyasevich
In-Reply-To: <CAFXGft+fwo=8LJEG7h6uOpGciSo5f_dXjSx3sn67RZZp7jsYHw@mail.gmail.com>
Hi,
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.
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,
^ permalink raw reply related
* Bug#776040: [PATCH] iproute2/ip: fix up filter when printing addresses
From: Andreas Henriksson @ 2015-01-23 12:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Andreas Henriksson, 776040
"ip addr show up" would exclude the interface (link), but include the
addresses of down interfaces (which looked like they where indented
under a different interface). This fixes the filtering.
For a full example see the original bug report at:
http://bugs.debian.org/776040
Reported-by: Paul Slootman <paul@debian.org>
CC: 776040@bugs.debian.org
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
---
ip/ipaddress.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index d5e863d..3730424 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -970,7 +970,8 @@ struct nlmsg_chain
struct nlmsg_list *tail;
};
-static int print_selected_addrinfo(int ifindex, struct nlmsg_list *ainfo, FILE *fp)
+static int print_selected_addrinfo(struct ifinfomsg *ifi,
+ struct nlmsg_list *ainfo, FILE *fp)
{
for ( ;ainfo ; ainfo = ainfo->next) {
struct nlmsghdr *n = &ainfo->h;
@@ -982,10 +983,13 @@ static int print_selected_addrinfo(int ifindex, struct nlmsg_list *ainfo, FILE *
if (n->nlmsg_len < NLMSG_LENGTH(sizeof(ifa)))
return -1;
- if (ifa->ifa_index != ifindex ||
+ if (ifa->ifa_index != ifi->ifi_index ||
(filter.family && filter.family != ifa->ifa_family))
continue;
+ if (filter.up && !(ifi->ifi_flags&IFF_UP))
+ continue;
+
print_addrinfo(NULL, n, fp);
}
return 0;
@@ -1446,7 +1450,7 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
if (no_link || (res = print_linkinfo(NULL, &l->h, stdout)) >= 0) {
struct ifinfomsg *ifi = NLMSG_DATA(&l->h);
if (filter.family != AF_PACKET)
- print_selected_addrinfo(ifi->ifi_index,
+ print_selected_addrinfo(ifi,
ainfo.head, stdout);
if (res > 0 && !do_link && show_stats)
print_link_stats(stdout, &l->h);
--
2.1.4
^ permalink raw reply related
* Re: net: prevent of emerging cross-namespace symlinks patches for 3.14?
From: Luis Henriques @ 2015-01-23 12:14 UTC (permalink / raw)
To: Miquel van Smoorenburg
Cc: netdev, stable, Alexander Y. Fomichev, David Miller
In-Reply-To: <54B6E36F.9060703@xs4all.net>
On Wed, Jan 14, 2015 at 10:45:19PM +0100, Miquel van Smoorenburg wrote:
> [first sent to lkml, now to netdev and the original patch author]
>
> When running 'lxc' on the latest -stable kernel, 3.14.28, I'm seeing these
> errors:
>
> Jan 14 17:47:16 lxc2 kernel: [ 10.704890] WARNING: CPU: 0 PID: 3209 at
> fs/sys
> fs/dir.c:52 sysfs_warn_dup+0x8c/0xb0()
> Jan 14 17:47:16 lxc2 kernel: [ 10.704892] sysfs: cannot create duplicate
> filename '/devices/virtual/net/eth0.104/upper_eth0'
> Jan 14 17:47:16 lxc2 kernel: [ 10.704954] CPU: 0 PID: 3209 Comm:
> lxc-autostart Not tainted 3.14.28-xsserver #1
>
> I did not see these errors in 3.12. This was fixed in 3.17 by:
>
> net: prevent of emerging cross-namespace symlinks
> https://github.com/torvalds/linux/commit/4c75431ac3520631f1d9e74aa88407e6374dbbc4
>
> net: fix creation adjacent device symlinks
> https://github.com/torvalds/linux/commit/7ce64c79c4decdeb1afe0bf2f6ef834b382871d1
>
> These patches apply cleanly to 3.14.28.
>
> If you agree that this should go into 3.14-stable, please ack.
>
Thank you, I am queuing these 2 patches for the 3.16 kernel as well.
Cheers,
--
Luís
> Thanks,
>
> Mike.
> --
> To unsubscribe from this list: send the line "unsubscribe stable" 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: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Hannes Frederic Sowa @ 2015-01-23 12:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Ahern, netdev
In-Reply-To: <20150122224033.6e2db5ce@urahara>
On Do, 2015-01-22 at 22:40 -0800, Stephen Hemminger wrote:
> On Wed, 14 Jan 2015 12:17:19 -0700
> David Ahern <dsahern@gmail.com> 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
> >
> > Suggested-by: Hannes Frederic Sowa <hannes@redhat.com>
> > Signed-off-by: David Ahern <dsahern@gmail.com>
> > Cc: Hannes Frederic Sowa <hannes@redhat.com>
>
> 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.
IPv6 is mostly a weak end model, too, but IFA_LINK addresses are used
much more. So yes, it is somewhere in between.
Addresses bound to interfaces which are currently down will work with
IPv6 (in contrast to IPv4).
> For vendors that control the application stack or have limited number
> of services this would work fine, but what about RHEL?
The new model is only enabled if the sysctl is set. I don't expect a lot
of vendors or distributions switching anytime soon.
I wonder if we should try to come up with a way of IPV6_NEW_WORLD_ORDER
we can make some changes to the stack which align much better with the
RFCs, e.g. no default link local address generation, no default on-link
routes etc.
Bye,
Hannes
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Thomas Graf @ 2015-01-23 12:28 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, John Fastabend, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123113934.GD2065@nanopsycho.orion>
On 01/23/15 at 12:39pm, Jiri Pirko wrote:
> Maybe I did not express myself correctly. I do not care if this is
> exposed by rtnl or a separate genetlink. The issue still stands. And the
> issue is that the user have to use "the way A" to setup sw datapath and
> "the way B" to setup hw datapath. The preferable would be to have
> "the way X" which can be used to setup both sw and hw.
>
> And I believe that could be achieved. Consider something like this:
>
> - have cls_xflows tc classifier and act_xflows tc action as a wrapper
> (or api) for John's work. With possibility for multiple backends. The
> backend iface would looke very similar to what John has now.
> - other tc clses and acts will implement xflows backend
> - openvswitch datapath will implement xflows backend
> - rocker switch will implement xflows backend
> - other drivers will implement xflows backend
>
> Now if user wants to manipulate with any flow setting, he can just use
> cls_xflows and act_xflows to to that.
>
> This is very rough, but I just wanted to draw the picture. This would
> provide single entry to flow world manipulation in kernel, no matter if
> sw or hw.
If I understand this correctly then you propose to do the decision on
whether to implement a flow in software or offload it to hardware in the
xflows classifier and action. I had exactly the same architecture in mind
initially when I first approached this and wanted to offload OVS
datapath flows transparently to hardware.
If you look at this from the existing tc world then that makes a lot
of sense, in particular if you only support a single flat table with
wildcard flows and no priorities.
If you want to support priorities it already gets complicated. If flow
A, B, C are offloaded to hardware and the user then inserts a new flow
D with higher priority that can't be offloaded you need to figure out
whether you have to remove any of A, B, C from the hardware tables again
on the basis whether D overlaps with A, B, or C. If you have to remove
any of them you then have to verify whether that removal needs to
remove other already offloaded flows as well. It's certainly doable but
already adds considerable complexity to the kernel.
If you want to support multiple tables it gets even more complicated
because a flow in table 2 which can be offloaded might depend on a
flow in table 1 which can't be offloaded. You somehow need to track
that dependency and ensure that table 1 sends that flow to the CPU so
that the flow in table 2 sees it. The answer to this might be to maybe
only support offload to a single table but that decreases the value
of the offload dramatically because the capabilities of each table are
very different.
If you bring the full programmability of OVS into the picture you might
have a pipeline consisting of multiple tables like this:
+-------+ +------+ +-----+ +-------+
| Decap |-->| L2 |-->| L3 |-->| Encap |
+-------+ +------+ +-----+ +-------+
Each table contains flows and metadata registers plus header matches
are used to talk among the tables. The pipeline builds a chain of
actions which may be executed at any point in the pipeline or at the
end. If you want to map such a software pipeline to a set of hardware
tables you need to have full visbility into this table structure at
the point where you make the offload decision. This means that all of
this complexity would have to move into xflows.
Another aspect is that you might want to split a flow X into a hardware
and software part, e.g. consider the following flow:
in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),nfqueue(10),output(tap0)
The hardware might be capable of matching on the VXLAN VNI, IP dst and
it might also capable of deencap. It obviously doesn't know about
netfilter queues. Ideally what you want is to split this into the
following flows:
Hardware table (offloaded):
in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),metadata=1
Software table:
metadata=1,actions=nfqueue(10),output(tap0)
If the hardware capabilities are not exported to OVS then xflows would
need to encode such logic and xflows would need to be made aware of the
full software pipeline with all tables as you need to see all flows in
order to decide what to offload where.
I would love to see a tc interface to John's flow API and I see
tremendous value but I don't think it's appropriate to offload OVS.
^ permalink raw reply
* Re: [PATCH] net: ieee802154: cc2520: Fix coding style issues
From: Sergei Shtylyov @ 2015-01-23 12:37 UTC (permalink / raw)
To: Mohammad Jamal, varkabhadram, alex.aring, linux-wpan, netdev,
linux-kernel
In-Reply-To: <1422005180-13230-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hello.
On 1/23/2015 12:26 PM, Mohammad Jamal wrote:
> This patch solves the coding style issues such as space after ,
s/after/before/?
> and removes the blank lines
Extra blank lines, you mean?
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index f9df9fa..dd129be 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
[...]
> @@ -551,14 +550,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
> u8 rssi;
> int ret;
>
> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
> if (ret)
> return ret;
>
> if (status != RSSI_VALID)
> return -EINVAL;
>
> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: ieee802154: cc2520: Fix coding style issues
From: Jamal Mohammad @ 2015-01-23 12:44 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Varka Bhadram, Alexander Aring, linux-wpan - ML,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <54C2409A.6020506@cogentembedded.com>
On Fri, Jan 23, 2015 at 6:07 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 1/23/2015 12:26 PM, Mohammad Jamal wrote:
>
>> This patch solves the coding style issues such as space after ,
>
>
> s/after/before/?
>
>> and removes the blank lines
>
>
> Extra blank lines, you mean?
>
>> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
>> ---
>> drivers/net/ieee802154/cc2520.c | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>
>
>> diff --git a/drivers/net/ieee802154/cc2520.c
>> b/drivers/net/ieee802154/cc2520.c
>> index f9df9fa..dd129be 100644
>> --- a/drivers/net/ieee802154/cc2520.c
>> +++ b/drivers/net/ieee802154/cc2520.c
>
> [...]
>>
>> @@ -551,14 +550,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
>> u8 rssi;
>> int ret;
>>
>> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
>> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
>> if (ret)
>> return ret;
>>
>> if (status != RSSI_VALID)
>> return -EINVAL;
>>
>> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
>> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
>
> [...]
>
> WBR, Sergei
>
Sorry for that,
i actually have cloned and linus torvalds git and when i ran
checkpatch.pl i have found some warnings. so this patch was removing
those warnings...as bhadram told that these warnings are already
removed in bluetooth-next tree...so this patch any how fails....
^ permalink raw reply
* RE: [PATCH net-next v3 3/5] bridge: offload bridge port attributes to switch asic if feature flag set
From: Rosen, Rami @ 2015-01-23 12:53 UTC (permalink / raw)
To: roopa@cumulusnetworks.com, jiri@resnulli.us, sfeldma@gmail.com,
jhs@mojatatu.com, bcrl@kvack.org, tgraf@suug.ch,
john.fastabend@gmail.com, stephen@networkplumber.org,
vyasevic@redhat.com, Arad, Ronen
Cc: netdev@vger.kernel.org, davem@davemloft.net,
shm@cumulusnetworks.com, gospo@cumulusnetworks.com
In-Reply-To: <1421987606-10884-4-git-send-email-roopa@cumulusnetworks.com>
Hi,
There is another Linux Ethernet driver which defines the ndo_bridge_setlink() callback, which is not included in the patch. It is the
Emulex ServerEngines' 10Gbps NIC (BladeEngine) (drivers/net/ethernet/emulex/benet).
So once the CONFIG_BE2NET kernel config item is set, running make will emit a compile warning.
Regards,
Rami Rosen
Intel Corporation
^ permalink raw reply
* NetDev 0.1 conference: Important! Hotel Reservation Deadline Expiring
From: Jamal Hadi Salim @ 2015-01-23 13:27 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
Cc: Richard Guy Briggs, info, speakers, attendees
Fellow netheads:
On behalf of rgb, yours truly is sending out this announcement.
Today is the last day that the Westin Hotel will be holding a block of
rooms for Netdev01 at a guaranteed rate of $159.00 or $179.00
(depending on the type of room required) and there are still rooms
available.
Please dont procastinate and book now. We are trying to negotiate with
the hotel to see if they can extend the deadline but so far we have not
been successful. We are competing against a few tourist activities for
hotel rooms going on around the area at the same time (example:
http://www.ottawafestivals.ca/events/winterlude-2/) so we can assure you
the prices will go up.
The content of the Tutorials/BOFs/talk continues to be updated at:
https://www.netdev01.org/sessions
This has to be the most amazing Linux netdev content put together
anywhere.
Avoid disappointment and do your reservations at:
https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802&key=1AC9C1F8
cheers,
jamal (on behalf of Richard Guy Briggs)
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jiri Pirko @ 2015-01-23 13:43 UTC (permalink / raw)
To: Thomas Graf
Cc: Jamal Hadi Salim, Pablo Neira Ayuso, John Fastabend, simon.horman,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150123122838.GI25797@casper.infradead.org>
Fri, Jan 23, 2015 at 01:28:38PM CET, tgraf@suug.ch wrote:
>On 01/23/15 at 12:39pm, Jiri Pirko wrote:
>> Maybe I did not express myself correctly. I do not care if this is
>> exposed by rtnl or a separate genetlink. The issue still stands. And the
>> issue is that the user have to use "the way A" to setup sw datapath and
>> "the way B" to setup hw datapath. The preferable would be to have
>> "the way X" which can be used to setup both sw and hw.
>>
>> And I believe that could be achieved. Consider something like this:
>>
>> - have cls_xflows tc classifier and act_xflows tc action as a wrapper
>> (or api) for John's work. With possibility for multiple backends. The
>> backend iface would looke very similar to what John has now.
>> - other tc clses and acts will implement xflows backend
>> - openvswitch datapath will implement xflows backend
>> - rocker switch will implement xflows backend
>> - other drivers will implement xflows backend
>>
>> Now if user wants to manipulate with any flow setting, he can just use
>> cls_xflows and act_xflows to to that.
>>
>> This is very rough, but I just wanted to draw the picture. This would
>> provide single entry to flow world manipulation in kernel, no matter if
>> sw or hw.
>
>If I understand this correctly then you propose to do the decision on
>whether to implement a flow in software or offload it to hardware in the
>xflows classifier and action. I had exactly the same architecture in mind
>initially when I first approached this and wanted to offload OVS
>datapath flows transparently to hardware.
Think about xflows as an iface to multiple backends, some sw and some hw.
User will be able to specify which backed he wants to use for particular
"commands".
So for example, ovs kernel datapath module will implement an xflows
backend and register it as "ovsdp". Rocker will implement another xflows
backend and register it as "rockerdp". Then, ovs userspace will use xflows
api to setup both backends independently, but using the same xflows api.
It is still up to userspace to decide what should be put where (what
backend to use).
>
>If you look at this from the existing tc world then that makes a lot
>of sense, in particular if you only support a single flat table with
>wildcard flows and no priorities.
>
>If you want to support priorities it already gets complicated. If flow
>A, B, C are offloaded to hardware and the user then inserts a new flow
>D with higher priority that can't be offloaded you need to figure out
>whether you have to remove any of A, B, C from the hardware tables again
>on the basis whether D overlaps with A, B, or C. If you have to remove
>any of them you then have to verify whether that removal needs to
>remove other already offloaded flows as well. It's certainly doable but
>already adds considerable complexity to the kernel.
>
>If you want to support multiple tables it gets even more complicated
>because a flow in table 2 which can be offloaded might depend on a
>flow in table 1 which can't be offloaded. You somehow need to track
>that dependency and ensure that table 1 sends that flow to the CPU so
>that the flow in table 2 sees it. The answer to this might be to maybe
>only support offload to a single table but that decreases the value
>of the offload dramatically because the capabilities of each table are
>very different.
>
>If you bring the full programmability of OVS into the picture you might
>have a pipeline consisting of multiple tables like this:
>
> +-------+ +------+ +-----+ +-------+
> | Decap |-->| L2 |-->| L3 |-->| Encap |
> +-------+ +------+ +-----+ +-------+
>
>Each table contains flows and metadata registers plus header matches
>are used to talk among the tables. The pipeline builds a chain of
>actions which may be executed at any point in the pipeline or at the
>end. If you want to map such a software pipeline to a set of hardware
>tables you need to have full visbility into this table structure at
>the point where you make the offload decision. This means that all of
>this complexity would have to move into xflows.
>
>Another aspect is that you might want to split a flow X into a hardware
>and software part, e.g. consider the following flow:
>
>in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),nfqueue(10),output(tap0)
>
>The hardware might be capable of matching on the VXLAN VNI, IP dst and
>it might also capable of deencap. It obviously doesn't know about
>netfilter queues. Ideally what you want is to split this into the
>following flows:
>
>Hardware table (offloaded):
>in_port=vxlan0,vni=10,ip_dst=10.1.1.1,actions=decap(),metadata=1
>
>Software table:
>metadata=1,actions=nfqueue(10),output(tap0)
>
>If the hardware capabilities are not exported to OVS then xflows would
>need to encode such logic and xflows would need to be made aware of the
>full software pipeline with all tables as you need to see all flows in
>order to decide what to offload where.
>
>I would love to see a tc interface to John's flow API and I see
>tremendous value but I don't think it's appropriate to offload OVS.
^ permalink raw reply
* [PATCH bluetooth-next] ieee802154: cc2520: Fix space before , coding style issue
From: Mohammad Jamal @ 2015-01-23 13:55 UTC (permalink / raw)
To: varkabhadram, alex.aring, linux-wpan, netdev, linux-kernel; +Cc: Mohammad Jamal
This patch removes the warnings (space before , ) shown by
checkpatch.pl
Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
---
drivers/net/ieee802154/cc2520.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index a43c8ac..665a3db 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -549,14 +549,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
u8 rssi;
int ret;
- ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
+ ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
if (ret)
return ret;
if (status != RSSI_VALID)
return -EINVAL;
- ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
+ ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
if (ret)
return ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next] bonding: handle more gso types
From: Eric Dumazet @ 2015-01-23 13:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Or Gerlitz
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)
+
+#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;
}
^ permalink raw reply related
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