RE: linux-next: Tree for Jul 26

Hi Sergey, Paolo Abeni had sent a patch: https://www.mail-archive.com/netdev@vger.kernel.org/msg179192.html Regards, Rami Rosen -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Sergey Senozhatsky Sent: Wednesday, July 26, 2017

RE: [PATCH net-next] genetlink: remove ops_list from genetlink header.

Hi, Sergei, Thanks! I will send V2 with 12 digits for the commit. Regards, Rami Rosen -Original Message- From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] Sent: Sunday, June 04, 2017 20:18 To: Rosen, Rami <rami.ro...@intel.com>; da...@davemloft.net Cc:

RE: [PATCH net-next 1/8] net: ipv4: refactor __ip_route_output_key_hash

Hi, Rupa /David Ahern, First, thanks for this patch set! Second, it seems to me that something might be incorrect here. You have these additions in this patch (1/8): ... +struct rtable *ip_route_output_key_hash_rcu(struct net *net, struct flowi4 *flp, +

RE: iproute2: using .maxattr = IFLA_VLAN_MAX??

Hi, Murali, > This appears to be a cut-n-paste bug as the source is based on > ip/iplink_vlan.c and should be fixed to IFLA_HSR_MAX. You are right. The "HSR section" indeed defines IFLA_HSR_MAX in include/linux/if_link.h of iproute2 as the max attributes number. And in the top of

RE: [RFC PATCH net-next 4/5] bridge: vlan lwt and dst_metadata netlink support

Hi, Roopa, Two minor comments: The parameter br is not used in the br_add_vlan_tunnel_info() method, it should be removed: +static int br_add_vlan_tunnel_info(struct net_bridge *br, + struct net_bridge_port *p, int cmd, + u16

RE: [PATCH iproute2] Revert "man pages: add man page for skbmod action"

Acked-by: Rami Rosen -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Jiri Benc Sent: Wednesday, January 18, 2017 14:37 To: netdev@vger.kernel.org Cc: Lucas Bates ; Jamal Hadi Salim

RE: [net-next 15/21] ixgbe: Configure advertised speeds correctly for KR/KX backplane

Hi, Hi, On this occasion, also the next can be fixed: > From: Don Skidmore > > This patch ensures that the advertised link speeds are configured for > X553 KR/KX backplane. Without this patch the link remains at 1G when > resuming form low power after being

RE: [PATCH iproute2 2/2] tc/act_tunnel: Introduce ip tunnel action

Hi, Amir, Following are three minor comments: Seems that TCA_TUNNEL_KEY_PAD used anywhere: + TCA_TUNNEL_KEY_PAD, + __TCA_TUNNEL_KEY_MAX, +}; Should be "and destination IP 11.11.0.2" instead of "and destination IP 11.11.0.1": +Tunnel ID (for example VNI in VXLAN tunnel) .TP .B

RE: [ANNOUNCE] bridge-utils 1.6 release

Hi, Alexander, >This link seems to be broken. Seems that it should be: https://www.kernel.org/pub/linux/utils/net/bridge-utils/bridge-utils-1.6.tar.gz Instead of: > > http://www.kernel.org/pub/linux/utils/net/bridge-utils/bridge-utils.1.6.tar.gz Regards, Rami Rosen Intel Corporation

RE: [PATCH net-next V5 4/4] net/sched: Introduce act_tunnel_key

Hi, Hadar, >For example, the following flower filter will forward all ICMP packets >destined to 11.11.11.2 >through the shared vxlan device 'vxlan0'. Before >redirecting, a metadata for the vxlan tunnel >is created using the tunnel_key >action and it's arguments: Shouldn't it be "tc filter

RE: [PATCH v3 5/8] thunderbolt: Communication with the ICM (firmware)

Hi, Amir, >This patch is the communication with the FW. >The network functionality is added in the next patches in the series >and with it, more messages from FW. >Indeed this function always returns true in this patch, >but while writing it, I predicted that the network functionality will

RE: [PATCH v3 5/8] thunderbolt: Communication with the ICM (firmware)

Hi Amir, Here are my 2 cents: This method always returns true, should be void (unless you will change PDF_ERROR_NOTIFICATION or other pdf values to return false), and likewise its invocation should not check return value. > +static bool nhi_msg_from_icm_analysis(struct tbt_nhi_ctxt

RE: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

Hi all, A very limited review below. + + /* get capabilities of particular feature */ + ENA_ADMIN_GET_FEATURE = 8, Instead /* get capabilities SHOULD BE: /* set capabilities . + + /* get capabilities of particular feature */ + ENA_ADMIN_SET_FEATURE = 9, + ..

RE: [PATCH] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

Hi, Netanel, +into 5 levels and assignes interrupt delay value to each level. Should be: assigns +The ENA device AQ and AENQ are allocated on probe and freed ontermination. Should be: on termination. + /* commit previously loaded firmare */ Should be: firmware +static int

RE: [PATCH net-next RFC] rtnetlink: add new RTM_GETSTATS to dump link stats

Hi, + if (!dev) + return -ENODEV; + + nskb = nlmsg_new(if_nlmsg_stats_size(dev), GFP_KERNEL); + if (!nskb) + return -ENOBUFS; + + err = rtnl_fill_statsinfo(nskb, dev, RTM_NEWSTATS, + NETLINK_CB(skb).portid,

RE: [PATCH iproute2] bridge: add support for dynamic fdb entries

+1 Rami Rosen Intel Corporation

RE: [patch net-next RFC 0/6] Introduce devlink interface and first drivers to use it

Hi, >Btw, if you add this tool into iproute2 (which would be preferred), >then >probably dl should be ok (and easier retrievable in that relation). +1. This tool, which uses netlink messages, seems a natural candidate for iproute2. And also apart from "ip", we have also another short command

RE: [PATCH iproute2] bridge: support for static fdb entries

+1 'temp' seems indeed not to be intuitive enough as 'static' in this context. Regards, Rami Rosen Intel Corporation -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Roopa Prabhu Sent: Wednesday, January 27, 2016 7:10 PM To:

RE: HW communication debugging interface - ideas?

Hi, Jiri, >In our case, we put message into skb and ... Just to be sure we are on the same page: By "In our case" - I assume you are referring to the mlxsw Ethernet switch driver, right ? >we put message into skb and push that out as an ordinary packet. >HW then > >sends us reply in a

RE: [patch net-next RFC 0/6] switchdev: introduce tranction enfra and for pre-commit split

Hi, >introduce tranction enfra and for pre-commit split Typo: Instead "tranction enfra" should be "transaction infrastructure". Regards, Rami Rosen Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More

RE: list of all network namespaces

Hi, >Presumably you could copy what "ip netns" does, which appears to be to look in >/var/run/netns . At least that is what an strace of that >command suggests. This is true, but keep in mind that the output of "ip netns", as well as listing the contents of /var/run/netns, reflects only

RE: [PATCH] bridge: Enable configuration of ageing interval for bridges and switch devices.

Hi, Prem, I recall that there was a patch proposed to prevent ageing of fdb entried by bridge in kernel, when the fdb entry was added due to notification by switch device. Please see: http://www.spinics.net/lists/netdev/msg314770.html Somehow the patch is not visible in the net-next pull.

RE: [PATCH] bridge: Enable configuration of ageing interval for bridges and switch devices.

Hi, First, I agree about the need to propagate the ageing interval to switchdev devices, so that hardware based aging can be setup correctly. Second, in this occasion, I want to mention the need to turn off bridge ageing in the kernel as part of using switchdev devices. This is mentioned in

RE: [patch net-next 4/4] mlxsw: Introduce Mellanox SwitchX-2 ASIC support

Hi, Jiri, Keep on the good work! The .func member of the mlxsw_rx_listener object has this prototype: void (*func)(struct sk_buff *skb, u8 local_port, u16 trap_id, void *priv); Is the trap_id parameter needed ? In the three use cases of .func, which are either mlxsw_emad_rx_listener_func(),