* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Herbert Xu @ 2015-01-09 2:34 UTC (permalink / raw)
To: Dennis Chen; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <CA+U0gVgS7z601DZvL82EJfYGYb5XQExw9CbnPRpUeN32TWLF7w@mail.gmail.com>
On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>
> Thanks, would you pls give me an example of those drivers? I'll study
> it further...
There are no known drivers doing this currently since that would
be a bug and they would be fixed quickly. But if you look back
in history virtio_net was doing this.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109023421.GA16089@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:34 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>>
>> Thanks, would you pls give me an example of those drivers? I'll study
>> it further...
>
> There are no known drivers doing this currently since that would
> be a bug and they would be fixed quickly. But if you look back
> in history virtio_net was doing this.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
So the only reason for the code '!list_empty()' I can see is to avoid
possible bug code in new drivers, thus pls think if it's possible
that there's a window opened for creating multiple NAPI instances in
the list for the new drivers?
--
Den
^ permalink raw reply
* Re: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
From: Ahmed S. Darwish @ 2015-01-09 3:06 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <54AE6FC1.6050007@pengutronix.de>
On Thu, Jan 08, 2015 at 12:53:37PM +0100, Marc Kleine-Budde wrote:
> On 01/05/2015 07:31 PM, Ahmed S. Darwish wrote:
> >
[...]
> >
> > cf->can_id |= CAN_ERR_CRTL;
> > cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
> >
> > stats->rx_over_errors++;
> > stats->rx_errors++;
> >
> > netif_rx(skb);
> >
> > stats->rx_packets++;
> > stats->rx_bytes += cf->can_dlc;
>
> Another patch would be not to touch cf after netif_rx(), please move the stats handling before calling netif_rx(). Same applies to the kvaser_usb_rx_can_msg() function.
>
BTW, is it guaranteed from the SocketCAN stack that netif_rx()
will never return NET_RX_DROPPED? Because if no guarantee
exists, I guess below fragment cannot be completely correct?
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
netif_rx(skb);
On the other hand, I don't see evan a single CAN driver checking
netif_rx() return value, so maybe such a check is an overkill...
Thanks,
Darwish
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 3:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109023421.GA16089@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:34 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>>
>> Thanks, would you pls give me an example of those drivers? I'll study
>> it further...
>
> There are no known drivers doing this currently since that would
> be a bug and they would be fixed quickly. But if you look back
> in history virtio_net was doing this.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Is this the below patch you mentioned?
https://lkml.org/lkml/2014/7/23/134
--
Den
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: David Miller @ 2015-01-09 3:12 UTC (permalink / raw)
To: kernel.org.gnu; +Cc: eric.dumazet, netdev, herbert
In-Reply-To: <CA+U0gVi1cVB4qbXAkPp1LMmNOaDOD2UaAL4riA6O_Q_SnvMQTA@mail.gmail.com>
From: Dennis Chen <kernel.org.gnu@gmail.com>
Date: Fri, 9 Jan 2015 10:26:48 +0800
> I am very curious about the reason that you're removing the atomic ops
> in the stack, what's the benifit?
1) Do not top post.
2) The reason is, obviously, performance.
^ permalink raw reply
* Re: [Patch net-next] ipv6: fix redefinition of in6_pktinfo and ip6_mtuinfo
From: David Miller @ 2015-01-09 3:38 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, carlos, vlee
In-Reply-To: <1420587932-8733-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 6 Jan 2015 15:45:31 -0800
> Both netinet/in.h and linux/ipv6.h define these two structs,
> if we include both of them, we got:
>
> /usr/include/linux/ipv6.h:19:8: error: redefinition of ‘struct in6_pktinfo’
> struct in6_pktinfo {
> ^
> In file included from /usr/include/arpa/inet.h:22:0,
> from txtimestamp.c:33:
> /usr/include/netinet/in.h:524:8: note: originally defined here
> struct in6_pktinfo
> ^
> In file included from txtimestamp.c:40:0:
> /usr/include/linux/ipv6.h:24:8: error: redefinition of ‘struct ip6_mtuinfo’
> struct ip6_mtuinfo {
> ^
> In file included from /usr/include/arpa/inet.h:22:0,
> from txtimestamp.c:33:
> /usr/include/netinet/in.h:531:8: note: originally defined here
> struct ip6_mtuinfo
> ^
> So similarly to what we did for in6_addr, we need to sync with
> libc header on their definitions.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next] doc: fix the compile error of txtimestamp.c
From: David Miller @ 2015-01-09 3:38 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, carlos, vlee
In-Reply-To: <1420587932-8733-2-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 6 Jan 2015 15:45:32 -0800
> Vinson reported:
>
> HOSTCC Documentation/networking/timestamping/txtimestamp
> Documentation/networking/timestamping/txtimestamp.c:64:8: error:
> redefinition of ‘struct in6_pktinfo’
> struct in6_pktinfo {
> ^
> In file included from /usr/include/arpa/inet.h:23:0,
> from Documentation/networking/timestamping/txtimestamp.c:33:
> /usr/include/netinet/in.h:456:8: note: originally defined here
> struct in6_pktinfo
> ^
>
> After we sync with libc header, we don't need this ugly hack any more.
>
> Reported-by: Vinson Lee <vlee@twopensource.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] Add support for few debugfs entries
From: David Miller @ 2015-01-09 3:40 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan, anish
In-Reply-To: <1420600683-23289-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 7 Jan 2015 08:47:59 +0530
> This patch series adds support for devlog, cim_la, cim_qcfg and mps_tcam
> debugfs entries.
>
> The patches series is created against 'net-next' tree.
> And includes patches on cxgb4 driver.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
Series applied, thanks.
^ permalink raw reply
* Re: [net v2 0/3][pull request] Intel Wired LAN Driver Updates 2015-01-06
From: David Miller @ 2015-01-09 3:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1420594317-6191-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 6 Jan 2015 17:31:54 -0800
> This series contains fixes to i40e only.
>
> Jesse provides a fix for when the driver was polling with interrupts
> disabled the hardware would occasionally not write back descriptors.
> His fix causes the driver to detect this situation and force an interrupt
> to fire which will flush the stuck descriptor.
>
> Anjali provides a couple of fixes, the first corrects an issue where
> the receive port checksum error counter was incrementing incorrectly with
> UDP encapsulated tunneled traffic. The second fix resolves an issue where
> the driver was examining the outer protocol layer to set the inner protocol
> layer checksum offload. In the case of TCP over IPv6 over an IPv4 based
> VXLAN, the inner checksum offloads would be set to look for IPv4/UDP
> instead of IPv6/TCP, so fixed the issue so that the driver will look at
> the proper layer for encapsulation offload settings.
>
> v2: fixed a bug in patch 01 of the series, where the interrupt rate impacted
> 4 port workloads by reducing throughput.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH -next] r8169: add support for xmit_more
From: David Miller @ 2015-01-09 3:51 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1420624189-24325-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 7 Jan 2015 10:49:49 +0100
> Delay update of hw tail descriptor if we know that another skb is going
> to be sent.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/7] Involve rhashtable_lookup_insert routine
From: David Miller @ 2015-01-09 3:48 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion, tgraf
In-Reply-To: <1420609318-3261-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Wed, 7 Jan 2015 13:41:51 +0800
> The series aims to involve rhashtable_lookup_insert() to guarantee
> that the process of lookup and insertion of an object from/into hash
> table is finished atomically, allowing rhashtable's users not to
> introduce an extra lock during search and insertion. For example,
> tipc socket is the first user benefiting from this enhancement.
Looks good, series applied.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
^ permalink raw reply
* Re: [PATCH net] netlink: fix wrong subscription bitmask to group mapping in binding callbacks
From: David Miller @ 2015-01-09 4:04 UTC (permalink / raw)
To: pablo; +Cc: netdev
In-Reply-To: <1420633915-25475-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 7 Jan 2015 13:31:55 +0100
> The subscription bitmask passed via struct sockaddr_nl is converted to
> the group number when calling the netlink_bind() and netlink_unbind()
> callbacks.
>
> The conversion is however incorrect since bitmask (1 << 0) needs to be
> mapped to group number 1. Note that you cannot specify the group number 0
> (usually known as _NONE) from setsockopt() using NETLINK_ADD_MEMBERSHIP
> since this is rejected through -EINVAL.
>
> This problem became noticeable since 97840cb ("netfilter: nfnetlink:
> fix insufficient validation in nfnetlink_bind") when binding to bitmask
> (1 << 0) in ctnetlink.
>
> Reported-by: Andre Tomt <andre@tomt.net>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This gets rejects when I try to apply it to 'net', please
respin.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] Revert "ARM: imx: add FEC sleep mode callback function"
From: David Miller @ 2015-01-09 4:05 UTC (permalink / raw)
To: festevam; +Cc: shawn.guo, fugang.duan, netdev, fabio.estevam
In-Reply-To: <1420634393-30027-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Wed, 7 Jan 2015 10:39:52 -0200
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> i.MX platform maintainer Shawn Guo is not happy with the such commit as
> explained below [1]:
>
> "The GPR difference between SoCs can be encoded in device tree as well.
> It's pointless to repeat the same code pattern for every single
> platform, that need to set up GPR bits for enabling magic packet wake
> up, while the only difference is the register and bit offset.
>
> The platform code will become quite messy and unmaintainable if every
> device driver dump their GPR register setup code into platform.
>
> Sorry, but it's NACK from me."
>
> This reverts commit 456062b3ec6f5b9 ("ARM: imx: add FEC sleep mode callback
> function").
>
> [1] http://www.spinics.net/lists/netdev/msg310922.html
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] Revert "ARM: dts: imx6qdl: enable FEC magic-packet feature"
From: David Miller @ 2015-01-09 4:05 UTC (permalink / raw)
To: festevam; +Cc: shawn.guo, fugang.duan, netdev, fabio.estevam
In-Reply-To: <1420634393-30027-2-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Wed, 7 Jan 2015 10:39:53 -0200
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> As 456062b3ec6f ("ARM: imx: add FEC sleep mode callback function") has been
> reverted, also revert the dts part.
>
> This reverts commit 07b4d2dda0c00f56248 ("ARM: dts: imx6qdl: enable FEC
> magic-packet feature").
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy parameter
From: David Miller @ 2015-01-09 4:08 UTC (permalink / raw)
To: David.Laight; +Cc: hau, netdev, nic_swsd, linux-kernel
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAC2C99@AcuExch.aculab.com>
From: David Laight <David.Laight@ACULAB.COM>
Date: Wed, 7 Jan 2015 16:45:58 +0000
> From: Chunhao Lin
>> @@ -5852,7 +5852,9 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
>> { 0x06, 0x00c0, 0x0020 },
>> { 0x08, 0x0001, 0x0002 },
>> { 0x09, 0x0000, 0x0080 },
>> - { 0x19, 0x0000, 0x0224 }
>> + { 0x19, 0x0000, 0x0224 },
>> + { 0x00, 0x0000, 0x0008 },
>> + { 0x0c, 0x3df0, 0x0200 }
>
> I can't help feeling these lines all require short comments.
Agreed.
And this goes for some of the other patches that look like this too.
^ permalink raw reply
* Re: [PATCH] csiostor:firmware upgrade fix
From: David Miller @ 2015-01-09 4:12 UTC (permalink / raw)
To: praveenm; +Cc: netdev, linux-scsi, JBottomley, hch, hariprasad
In-Reply-To: <1420638388-9074-1-git-send-email-praveenm@chelsio.com>
From: Praveen Madhavan <praveenm@chelsio.com>
Date: Wed, 7 Jan 2015 19:16:28 +0530
> This patch fixes removes older means of upgrading Firmware using MAJOR version
> and adds newer interface version checking mechanism.
>
> Please apply this patch on net-next since it depends on previous commits.
>
> Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sh-eth: Set fdr_value of R-Car SoCs
From: David Miller @ 2015-01-09 4:07 UTC (permalink / raw)
To: nobuhiro.iwamatsu.yj; +Cc: netdev, yoshihiro.shimoda.uh, linux-sh
In-Reply-To: <1420609215-6969-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date: Wed, 7 Jan 2015 14:40:15 +0900
> FDR register of R-Car set in fdr_value can have the original settings.
> This sets the value that is suitable for each SoCs to fdr_value of R8A777x
> and R8A779x.
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] sh_eth: Fix access to TRSCER register
From: David Miller @ 2015-01-09 4:07 UTC (permalink / raw)
To: nobuhiro.iwamatsu.yj; +Cc: netdev, yoshihiro.shimoda.uh, linux-sh, geert
In-Reply-To: <1420698307-3707-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date: Thu, 8 Jan 2015 15:25:07 +0900
> TRSCER register is configured differently by SoCs. TRSCER of R-Car Gen2 is
> RINT8 bit only valid, other bits are reserved bits. This removes access to
> TRSCER register reserve bit by adding variable trscer_err_mask to
> sh_eth_cpu_data structure, set the register information to each SoCs.
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Applied.
^ permalink raw reply
* Re: pull request: batman-adv 20150108
From: David Miller @ 2015-01-09 4:14 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1420730120-9844-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Thu, 8 Jan 2015 16:15:05 +0100
> this is a batch of patches intended for net-next.
>
> In this patchset you have mostly cleanups and small corrections to issues
> reported by checkpatch.
>
> One notable change is the addition of the DEBUG_FS dependency to the
> BATMAN_ADV_DEBUG symbol by Markus Pargmann. We add this dependency because all
> the information provided by the DEBUG feature is accessible only through
> debugfs.
Pulled, thanks Antonio.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: Add ovs_vport_get_index() to hide vport implementation
From: Pravin Shelar @ 2015-01-09 4:10 UTC (permalink / raw)
To: Daniele Di Proietto; +Cc: netdev
In-Reply-To: <1420674525-18253-1-git-send-email-daniele.di.proietto@gmail.com>
On Wed, Jan 7, 2015 at 3:48 PM, Daniele Di Proietto
<daniele.di.proietto@gmail.com> wrote:
> datapath.c should not access private vport data. This commit adds
> 'ovs_vport_get_index()' to vport.c and '.get_index()' to vport_ops
> to hide vport implementation details.
>
Earlier patch was better. There is no need to introduce new
ovs_vport_get_index() since no other vport type can have ifindex.
^ permalink raw reply
* Re: [PATCH] net: fec: fix NULL pointer dereference in fec_enet_timeout_work
From: David Miller @ 2015-01-09 4:12 UTC (permalink / raw)
To: h.feurstein; +Cc: netdev, fabio.estevam, frank.li, linux-kernel
In-Reply-To: <1420638497-6871-1-git-send-email-hubert.feurstein@deto.at>
From: Hubert Feurstein <h.feurstein@gmail.com>
Date: Wed, 7 Jan 2015 14:48:17 +0100
> From: Hubert Feurstein <h.feurstein@gmail.com>
>
> This patch initialises the fep->netdev pointer. This pointer was not
> initialised at all, but is used in fec_enet_timeout_work and in some
> error paths.
>
> Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
Applied.
^ permalink raw reply
* [PATCH v2 net-next] bridge: Add ability to enable TSO
From: Toshiaki Makita @ 2015-01-09 5:16 UTC (permalink / raw)
To: David S . Miller, Stephen Hemminger; +Cc: netdev, bridge
Currently a bridge device turns off TSO feature if no bridge ports
support it. We can always enable it, since packets can be segmented on
ports by software as well as on the bridge device.
This will reduce the number of packets processed in the bridge.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
v2: Use an existing helper function.
net/bridge/br_if.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index ed307db..81e49fb 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -424,6 +424,7 @@ netdev_features_t br_features_recompute(struct net_bridge *br,
features = netdev_increment_features(features,
p->dev->features, mask);
}
+ features = netdev_add_tso_features(features, mask);
return features;
}
--
1.8.1.2
^ permalink raw reply related
* RE: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy parameter
From: Hau @ 2015-01-09 5:18 UTC (permalink / raw)
To: David Miller, David.Laight@ACULAB.COM
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <20150108.200858.548066819871890131.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, January 09, 2015 12:09 PM
> To: David.Laight@ACULAB.COM
> Cc: Hau; netdev@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy
> parameter
>
> From: David Laight <David.Laight@ACULAB.COM>
> Date: Wed, 7 Jan 2015 16:45:58 +0000
>
> > From: Chunhao Lin
> >> @@ -5852,7 +5852,9 @@ static void rtl_hw_start_8168f_1(struct
> rtl8169_private *tp)
> >> { 0x06, 0x00c0, 0x0020 },
> >> { 0x08, 0x0001, 0x0002 },
> >> { 0x09, 0x0000, 0x0080 },
> >> - { 0x19, 0x0000, 0x0224 }
> >> + { 0x19, 0x0000, 0x0224 },
> >> + { 0x00, 0x0000, 0x0008 },
> >> + { 0x0c, 0x3df0, 0x0200 }
> >
> > I can't help feeling these lines all require short comments.
>
> Agreed.
>
> And this goes for some of the other patches that look like this too.
>
I will merge the patches and update again.
Thanks.
------Please consider the environment before printing this e-mail.
^ permalink raw reply
* Re: IPsec workshop at netdev01?
From: Fan Du @ 2015-01-09 5:30 UTC (permalink / raw)
To: Steffen Klassert
Cc: netdev, Jamal Hadi Salim, Herbert Xu, David Miller, Du, Fan
In-Reply-To: <20150106101936.GC31458@secunet.com>
于 2015年01月06日 18:19, Steffen Klassert 写道:
> Is there any interest in doing an IPsec workshop at netdev01?
>
> This mail is to probe if we can gather enough discussion topics to run
> such a workshop. So if someone is interested to attend and/or has a
> related discussion topic, please let me know.
>
> The idea to do this workshop came yesterday, so I'm still collecting
> topics I'm interested in. Some things that came immediately to my mind
> are:
>
> - Our IPsec policy/state lookups are still hashlist based on slowpath with
> a flowcache to do fast lookups for traffic flows we have already seen.
> This flowcache has similar issues like the ipv4 routing chache had.
> Is the flowcache an appropriate lookup method on the long run or should
> we at least think about an additional alternative lookup method?
>
> - We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
> comes up from time to time. Some solutions were proposed in the past
> but all had problems. The current behaviour is broken if someone tries
> to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
> this right somehow or is it better to just return an error in this case?
Before a clean solution show up, I think it's better to warn user in some way
like http://patchwork.ozlabs.org/patch/323842/ did. Otherwise, many people
who stuck there will always spend time and try to fix this issue in whatever way.
> - Changing the system time can lead to unexpected SA lifetime changes. The
> discussion on the list did not lead to a conclusion on how to fix this.
> What is the best way to get this fixed?
I rise this issue long ago before, the culprit is SA lifetime is marked by wall clock.
In a reasonable way it should be marked as monotonic boot time(counting suspend time
as well). Then every thing will be work correctly. I have such a patch works correctly.
EXCEPT: SA migration, where SA lifetime comes from outside.
I didn't look at SA migration part though, so any comments? Steffen
--
No zuo no die but I have to try.
^ permalink raw reply
* [PATCH net-next 0/2] All Chelsio drivers : Cleanup CPL messages macros
From: Anish Bhatt @ 2015-01-09 5:38 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
roland-BHEL68pLQRGGvPXPguhicg, hch-wEGCiKHe2LqWVfeAwA7xHQ,
jbottomley-bzQdu9zFT3WakBO8gow8eQ,
hariprasad-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
kxie-ut6Up61K2wZBDgjK7y7TUQ, leedom-ut6Up61K2wZBDgjK7y7TUQ,
Anish Bhatt
This patch series cleans up all register defines/MACROS defined in t4_msg.h and
affected files as part of the continuing cleanup effort
The patches series is created against 'net-next' tree and includes patches
to the cxgb4, cxgb4vf, iw_cxgb4, cxgb4i and csiostor drivers.
We have included all the maintainers of respective drivers. Kindly review the
change and let us know in case of any review comments.
-Anish
Hariprasad Shenai (2):
RDMA/cxgb4/cxgb4i: Cleanup register defines/MACROS related to CM CPL
messages
RDMA/cxgb4/cxgb4vf/cxgb4i/csiostor: Cleanup register defines/MACROS
related to all other cpl
drivers/infiniband/hw/cxgb4/cm.c | 98 +++---
drivers/infiniband/hw/cxgb4/mem.c | 4 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 16 +-
drivers/net/ethernet/chelsio/cxgb4/l2t.c | 4 +-
drivers/net/ethernet/chelsio/cxgb4/sge.c | 9 +-
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 367 +++++++++++++++------
.../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 4 +-
drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 6 +-
drivers/scsi/csiostor/csio_lnode.c | 2 +-
drivers/scsi/csiostor/csio_scsi.c | 4 +-
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 18 +-
11 files changed, 356 insertions(+), 176 deletions(-)
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox