[PATCH 0/3] net/rds: SOL_RDS socket option to explicitly select transport

definitions needed by the application via linux/rds.h. Patch 2 provides the setsockopt support, and Patch 3 provides the getsockopt support. Sowmini Varadhan (3): Declare SO_RDS_TRANSPORT and RDS_TRANS_* constants in uapi/linux/rds.h Add setsockopt support for SO_RDS_TRANSPORT Add setsockopt

[PATCH 3/3] net/rds Add getsockopt support for SO_RDS_TRANSPORT

The currently attached transport for a PF_RDS socket may be obtained from user space by invoking getsockopt(2) using the SO_RDS_TRANSPORT option at the SOL_RDS level. The integer optval returned will be one of the RDS_TRANS_* constants defined in linux/rds.h. Signed-off-by: Sowmini Varadhan

[PATCH 1/3] net/rds: Declare SO_RDS_TRANSPORT and RDS_TRANS_* constants in uapi/linux/rds.h

., RDS_TRANS_TCP. This commit exports the constant values need by such applications via linux/rds.h Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- include/uapi/linux/rds.h | 10 ++ net/rds/rds.h|5 - 2 files changed, 10 insertions(+), 5 deletions(-) diff --git

[PATCH 2/3] net/rds: Add setsockopt support for SO_RDS_TRANSPORT

be specified before invoking bind(2) on the socket, and may only be used once on the socket. An attempt to set the option on a bound socket, or to invoke the option after a successful SO_RDS_TRANSPORT attachment, will return EOPNOTSUPP. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- net

[PATCH v2 net] net: sk_clone_lock() should only do get_net() if the parent is not a kernel socket

Dumazet eduma...@google.com Cc: Eric W. Biederman ebied...@xmission.com Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- v2: pulled patch #3 out of the RFC patch-set for RDS-TCP netns fixes; Added Fixes, Acked-by, Cc fields based on mailing list feedback from Eric Dumazet. net

[PATCH v2 net-next 0/2] RDS-TCP: Network namespace support

, patch 3 broken off and submitted separately. Sowmini Varadhan (2): Make RDS-TCP work correctly when it is set up in a netns other than init_net Support multiple RDS-TCP listen endpoints, one per netns. net/rds/bind.c|3 +- net/rds/connection.c | 16 +++-- net/rds

[PATCH v2 net-next 2/2] RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.

indicating that the netns is getting deleted. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- v2: net_device notifier for synchronous cleanup of sockets. net/rds/tcp.c | 163 - net/rds/tcp.h |7 ++- net/rds

[PATCH v2 net-next 1/2] RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net

Open the sockets calling sock_create_kern() with the correct struct net pointer, and use that struct net pointer when verifying the address passed to rds_bind(). Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- v2: David Ahern comments. net/rds/bind.c|3 ++- net/rds

[PATCH v3 net-next 2/2] RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.

indicating that the netns is getting deleted. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- v2: net_device notifier for synchronous cleanup of sockets. v3: Cong Wang comments net/rds/tcp.c | 161 - net/rds/tcp.h

[PATCH v3 net-next 0/2] RDS-TCP: Network namespace support

, patch 3 broken off and submitted separately. v3: Cong Wang review comments. Sowmini Varadhan (2): Make RDS-TCP work correctly when it is set up in a netns other than init_net Support multiple RDS-TCP listen endpoints, one per netns. net/rds/bind.c|3 +- net/rds

[PATCH v3 net-next 1/2] RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net

Open the sockets calling sock_create_kern() with the correct struct net pointer, and use that struct net pointer when verifying the address passed to rds_bind(). Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- v2: David Ahern comments. net/rds/bind.c|3 ++- net/rds

Re: [PATCH RFC net-next 1/3] RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net

On (07/30/15 11:03), David Ahern wrote: +write_pnet(conn-c_net, net); these are typically in wrappers like sock_net and sock_net_set : +conn = rds_conn_create(init_net, dp-dp_daddr, dp-dp_saddr, + rds_ib_transport, GFP_KERNEL); I forget what connection

[PATCH RFC net-next 2/3] RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.

that cleanup_net() will eventually complete, allowing the pernet -exit to be invoked. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- net/rds/tcp.c | 112 ++-- net/rds/tcp.h |7 ++- net/rds/tcp_connect.c |6

[PATCH RFC net-next 1/3] RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net

Open the sockets calling sock_create_kern() with the correct struct net pointer, and use the correct struct net pointer when verifying the address passed to rds_bind(). Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- net/rds/bind.c|3 ++- net/rds/connection.c | 16

[PATCH RFC net-next 0/3] RDS-TCP: Network namespace support

for lo to become free. Usage count .. being seen in the interval between ethernet device migration to init_net and the keepalive timeout Patch 3 in this set is independant of the above two changes, and is a bugfix/follow up to eeb1bd5c encountered while testing the above. Sowmini Varadhan

[PATCH RFC net-next 3/3] net/core/sock.c: sk_clone_lock() should only do get_net() if the parent is not a kernel socket

(listen) socket is a kernel socket (defined in sk_alloc() as having sk_net_refcnt == 0), then the newsk should also have a 0 sk_net_refcnt and should not hold a get_net() reference. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- net/core/sock.c |3 ++- 1 files changed, 2

netns refcnt leak for kernel accept sock

I'm running into a netns refcnt issue, and I suspect that eeb1bd5c has something to do with it (perhaps we need an additional change in sk_clone_lock() after eeb1bd5c). Here's the problem: When we create an syn_recv sock based on a kernel listen sock, we take a get_net() ref with a stack

Re: netns refcnt leak for kernel accept sock

On (07/27/15 12:40), ebied...@xmission.com wrote: sock_create_kern and friends are specialied interfaces for special purposes. At a quick read through I don't think we have a single in tree user doing with them what you are trying to do. That doesnt change the fact that the architecture is

Re: netns refcnt leak for kernel accept sock

On (07/27/15 11:13), Cong Wang wrote: That refcnt should be released in sock destructor too, when the tcp connection is terminated. yes, but in my case, the listen socket is opened as part of the -init indirection in pernet_operations (thus it is a kernel socket) and the expectation is that

Re: netns refcnt leak for kernel accept sock

On (07/27/15 11:37), Cong Wang wrote: dlm uses a kernel TCP socket too, but it allocates a new socket and calls -accept() by itself. ;) sure, and rds does this in rds_tcp_accept_one() too. But the newsk being created in sk_clone_lock is the one on an incoming syn, i.e., the one that is

Re: ARP response with link local IP, why not broadcast

On Tue, Jul 21, 2015 at 4:38 PM, Sebastian Fett db_ext...@gmx.de wrote: Hello! According to RFC3927 every ARP packet (reply and request) should be sent as link layer broadcast as long as the sender IP is a link local address. (see chapter 2.5). Because broadcast replies are noisy and should

Re: ARP response with link local IP, why not broadcast

On Wed, Jul 22, 2015 at 9:49 AM, Sebastian Fett db_ext...@gmx.de wrote: what is your use case? My problem ist a local network of audio devices. It is a valid possibility that two halfs of the setup are set up individually (Stage left and stage right). Both local networks will auto configure

rfc: making rds-tcp netns aware

I am working on making rds-tcp to be netns-aware, and in addition to a few bug fixes that I'm lining up, there's a basic issue with the way rds-tcp sets up the listen socket that is causing problems The RDS tcp listen endpoint is created as part of module init. (rds_tcp_init -

[PATCH RFC net-next] net/vxlan: Fix kernel unaligned access in __vxlan_find_mac

__vxlan_find_mac invokes ether_addr_equal on the eth_addr field, which triggers unaligned access messages, so rearrange vxlan_fdb to avoid this as non-intrusively as possible. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- drivers/net/vxlan.c |2 +- 1 files changed, 1

Re: [PATCHv2 RFC net-next] net/vxlan: Fix kernel unaligned access in __vxlan_find_mac

On (07/17/15 16:07), Joe Perches wrote: On Fri, 2015-07-17 at 22:00 +0200, Sowmini Varadhan wrote: __vxlan_find_mac invokes ether_addr_equal on the eth_addr field, which triggers unaligned access messages, so rearrange vxlan_fdb to avoid this in the most non-intrusive way. What arch does

[PATCHv2 RFC net-next] net/vxlan: Fix kernel unaligned access in __vxlan_find_mac

__vxlan_find_mac invokes ether_addr_equal on the eth_addr field, which triggers unaligned access messages, so rearrange vxlan_fdb to avoid this in the most non-intrusive way. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- v2: Alexander Duyck comments: make eth_addr[] 64b aligned

Re: [PATCHv2 RFC net-next] net/vxlan: Fix kernel unaligned access in __vxlan_find_mac

On 07/18/2015 08:06 PM, Joe Perches wrote: It seems that this code has had unaligned accesses on this field even before compare_ether_addr was converted to ether_addr_equal. Is sparc64 the only one that emits / ratelimits that unaligned access message? I looked a little, but I didn't find a

[PATCH v2 net-next] net/vxlan: Fix kernel unaligned access in __vxlan_find_mac

__vxlan_find_mac invokes ether_addr_equal on the eth_addr field, which triggers unaligned access messages, so rearrange vxlan_fdb to avoid this in the most non-intrusive way. Signed-off-by: Sowmini Varadhan sowmini.varad...@oracle.com --- v2: Alexander Duyck comments: place eth_addr[] to be 64b

[PATCH v2 net-next] xfrm: Fix unaligned access to stats in copy_to_user_state()

ligned, and this cannot be changed for nla_data() that is passed up to userspace. As a result, the put_unaligned() macro needs to be used to set up potentially unaligned fields such as the xfrm_stats in copy_to_user_state() Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2: re

[PATCH net] i40e: Look up MAC address in Open Firmware or IDPROM

. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- drivers/net/ethernet/intel/i40e/i40e_common.c | 36 + 1 files changed, 36 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_c

[PATCH net] RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv

in the same manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and retry via the deferred call to rds_send_worker() that gets set up on ENOMEM from rds_tcp_read_sock() Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- net/rds/tcp_recv.c | 11 +-- 1 files chan

Re: [PATCH net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

On (10/21/15 06:22), David Miller wrote: > memcpy() _never_ works for avoiding unaligned accessed. > > I repeat, no matter what you do, no matter what kinds of casts or > fancy typing you use, memcpy() _never_ works for this purpose. : > There is one and only one portable way to access

Re: Routing loops & TTL tracking with tunnel devices

On (11/16/15 21:14), Jason A. Donenfeld wrote: > > But what about in devices for which self-routing might actually be > useful? For example, let's say that if an incoming skb is headed for > dst X, it gets encapsulated and sent to dst A, and for dst Y it gets > encapsulated and sent to dst B, and

Re: Routing loops & TTL tracking with tunnel devices

> Neat. Though, in my case, I'm not actually just prepending a header. > I'm doing some more substantial transformations of a packet. And this > needs to work with v4 too. So I'm not sure implementing a v6 spec will Understood, that spec was just referenced to indicate that there are more issues

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (11/02/15 17:26), Nelson, Shannon wrote: > > I assume you mean .1q > > Yes, this is what I had in mind. I dont think we're quite there yet, even without vlans. If I turn on/off tcpdump, there's something about the way that the link is bounced that leaves the device down while tcpdump is

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (10/30/15 22:03), Nelson, Shannon wrote: > The more common idiom in our driver would be > > err = i40e_get_platform_mac_addr(..); > if (err) { Ok. > Have you tested this beyond a compile? > Do you have a DT model to try this against? yes. > In looking at a couple other drivers,

Re: [PATCH net] i40e: Look up MAC address in Open Firmware or IDPROM

On (10/30/15 02:14), Andy Shevchenko wrote: > > Does the following has no stubs? > > > + struct i40e_pf *pf = hw->back; > > + struct device_node *dp = pci_device_to_OF_node(pf->pdev); > > + const unsigned char *addr; > > + > > + addr = of_get_mac_address(dp); > > ^^^ I

[PATCH v2 net] i40e: Look up MAC address in Open Firmware or IDPROM

. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2: review comments from Andy Shevchenko drivers/net/ethernet/intel/i40e/i40e_common.c | 32 + 1 files changed, 32 insertions(+), 0 deletions(-) diff --git

[PATCH v4 RFC net] i40e: Look up MAC address in Open Firmware or IDPROM

f invoking i40e_macaddr_init() on platforms that use the default mac address (i.e., when it is not from OF or idprom) will cause harm, and if it is necessary/possible to move this invocation to an earlier point in i40e_probe(). Reviewed-by: Martin K. Petersen <martin.peter...@oracle.com> Signed

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (10/30/15 19:13), Sowmini Varadhan wrote: > > In looking at a couple other drivers, I see the difference being that > > they typically are writing the primary mac filter on probe (and any > > other reset), whereas the i40e "knows" that the default mac address is >

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (11/01/15 21:03), Nelson, Shannon wrote: > .. In the meantime, be sure to test what happens over a reset, such as what > happens when the MTU is changed. This will make sure that the replay > of mac and vlan filters happens correctly. You'll want to test this > with and without vlans. I

[PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2: andy shevchenko comments v3: more andy shevchenko comments drivers/net/ethernet/intel/i40e/i40e_common.c | 30 + 1 files changed, 30 insertions(+), 0 de

[PATCH v6] i40e: Look up MAC address in Open Firmware or IDPROM

. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2, v3: Andy Shevchenko comments v4: Shannon Nelson review: explicitly set up mac filters before register_netdev v5: Shannon Nelson code style comments v6: Shannon Nelson code style

Re: [PATCH v5] i40e: Look up MAC address in Open Firmware or IDPROM

On (11/04/15 21:59), Andy Shevchenko wrote: > > Usually the structure of kernel doc is something like following > > /** > * func - summary > * @paramx: desc > * > * Description: > * Long description in many lines and / or paragraphs > * > * Returns: > * 0 on success or errno otherwise. >

[PATCH v5] i40e: Look up MAC address in Open Firmware or IDPROM

. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2, v3: Andy Shevchenko comments v4: Shannon Nelson review: explicitly set up mac filters before register_netdev v5: Shannon Nelson code style comments drivers/net/ethernet/intel/i

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (11/02/15 14:57), Sowmini Varadhan wrote: > On (11/02/15 17:26), Nelson, Shannon wrote: > > > I assume you mean .1q > > > > Yes, this is what I had in mind. > > I dont think we're quite there yet, even without vlans. > Ok finally got all the .1q stuff

Re: [PATCH v6] i40e: Look up MAC address in Open Firmware or IDPROM

On (11/05/15 11:29), David Miller wrote: > > The intention is to let your patch go in as-is, then try and update > ixgbe/i40e later in net-next or similar. Sounds good, I can take care of ixgbe/i40e after that happens. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the

Re: [PATCH v6] i40e: Look up MAC address in Open Firmware or IDPROM

On (11/05/15 11:05), David Miller wrote: > From: David Miller > Date: Thu, 05 Nov 2015 10:31:26 -0500 (EST) > > > I'll see if I can cook something up. > > How does this look? Looks good to me, Do you want me to respin patch v7 with this? Or update ixgbe/i40e to use this

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (10/30/15 18:57), Nelson, Shannon wrote: > > > > > > Going along with this being the equivalent of the ixgbe patch, I'd > > > prefer the new code to be in i40e_main.c, rather than in i40e_common.c. > > > In the design of our drivers, the common file is essentially a device > > > specific layer,

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (10/30/15 20:06), Andy Shevchenko wrote: > > > +#include "i40e.h" > > Why do you need this one exactly? I needed it to find pf->pdev below. > > + struct device_node *dp = pci_device_to_OF_node(pf->pdev); Without it, you will get: : CC [M]

Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

On (10/30/15 18:28), Nelson, Shannon wrote: > > Going along with this being the equivalent of the ixgbe patch, I'd > prefer the new code to be in i40e_main.c, rather than in i40e_common.c. > In the design of our drivers, the common file is essentially a device > specific layer, and the OS and

[PATCH 0/2] xfrm/crypto: unaligned access fixes

A two-part patchset that fixes some "unaligned access" warnings that showed up my sparc test machines with ipsec set up. Sowmini Varadhan (2): crypto/x509: Fix unaligned access in x509_get_sig_params() Fix unaligned access in xfrm_notify_sa() for DELSA crypto/asymm

[PATCH 1/2] crypto/x509: Fix unaligned access in x509_get_sig_params()

alignment values into consideration when doing kzalloc() Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- crypto/asymmetric_keys/x509_public_key.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto

[PATCH net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

On sparc, deleting established SAs (e.g., by restarting ipsec at the peer) results in unaligned access messages via xfrm_del_sa -> km_state_notify -> xfrm_send_state_notify(). Use an aligned pointer to xfrm_usersa_info for this case. Signed-off-by: Sowmini Varadhan <sowmini.varad...@o

Re: [PATCH net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

On (10/21/15 06:54), Sowmini Varadhan wrote: > But __alignof__(*p) is 8 on sparc, and without the patch I get > all types of unaligned access. So what do you suggest as the fix? Even though the alignment is, in fact, 8 (and that comes from struct xfrm_lifetime_cfg), if uspace is firmly at

Re: [PATCH net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

On (10/21/15 08:57), Steffen Klassert wrote: > > --- a/net/xfrm/xfrm_user.c > > +++ b/net/xfrm/xfrm_user.c > > @@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, const > > struct km_event *c) > > if (attr == NULL) > > goto out_free_skb; > > > >

Re: [PATCH net-next] RDS: fix rds-ping deadlock over TCP transport

e pong has already been added to the sendq earlier.. in the case of IB, if RDS_LL_SEND_FULL has been set, it takes some head-scratching to figure out how the pong gets sent, and a few comments could help clarify that. but other than that, the contents look good to me, thus Acked-by: Sowmini Varad

Re: [PATCH v2 net-next] RDS: fix rds-ping deadlock over TCP transport

for transport like IB. Acked-by: Sowmini Varadhan <sowmini.varad...@oracle.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH net-next] RDS-TCP: Reset tcp callbacks if re-using an outgoing socket in rds_tcp_accept_one()

ng is set to 0 so that we do not trigger any reconnect attempts on the passive side of the tcp socket in the future, in conformance with commit c82ac7e69efe ("net/rds: RDS-TCP: only initiate reconnect attempt on outgoing TCP socket.") Signed-off-by: Sowmini Varadhan <sowmini.varad...@ora

[PATCH net-next] RDS: Invoke ->laddr_check() in rds_bind() for explicitly bound transports.

ces. Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- net/rds/bind.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/net/rds/bind.c b/net/rds/bind.c index bc6b93e..6192566 100644 --- a/net/rds/bind.c +++ b/net/rds/bind.c @@ -196,7 +196,

a question about the kcm proposal

Thinking back a bit about the kcm proposal: https://www.mail-archive.com/netdev@vger.kernel.org/msg78696.html I had a question: If the user-space has decided to encrypt the http/2 header using tls, the len (and other http/2 fields) is no longer in the clear for the kernel. My understanding is

Re: [PATCH net-next v4] net: ipv6: Make address flushing on ifdown optional

On Wed, Oct 7, 2015 at 11:17 AM, David Ahern wrote: > Currently, all ipv6 addresses are flushed when the interface is configured > down, including global, static addresses: : > > Add a new sysctl to make this behavior optional. The new setting defaults to > flush all

Re: a question about the kcm proposal

On (10/12/15 15:05), Tom Herbert wrote: > > There is a different but related problem in this space- existing TLS/DTLS > > libraries (openssl, gnutls etc) only know how to work with tcp > > or udp sockets - they do not know anything about PF_RDS or the > > newly proposed kcm socket type. > > >

Re: [RFC net-next 3/6] net: Introduce VRF device driver - v2

On Mon, Jul 6, 2015 at 5:03 PM, David Ahern d...@cumulusnetworks.com wrote: This driver borrows heavily from IPvlan and teaming drivers. Routing domains (VRF-lite) are created by instantiating a device and enslaving all routed interfaces that participate in the domain. As part of the

Re: [RFC net-next 3/6] net: Introduce VRF device driver - v2

On Thu, Jul 9, 2015 at 7:19 PM, David Ahern d...@cumulusnetworks.com wrote: On the to-do list to use cmsg to specify a VRF for outbound packets using non-connected sockets. I do not believe it is going to work, but need to look into it. What about setting ipsec policy for interfaces in the

Re: [RFC net-next 3/6] net: Introduce VRF device driver - v2

On Fri, Jul 10, 2015 at 4:39 AM, David Ahern d...@cumulusnetworks.com wrote: If I set the VRF context (ie., set the SO_BINDTODEVICE for all sockets) of any RDS, NFS or any other socket app it runs in that VRF context and works just fine What if the application wants to do SO_BINDTODEVICE? --

[PATCH net-next] RDS: rds_conn_lookup() should factor in the struct net for a match

Only return a conn if the rds_conn_net(conn) matches the struct net passed to rds_conn_lookup(). Fixes: 467fa15356ac ("RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.") Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- net/rds/con

Re: [PATCH RFC 0/5] net: L2 only interfaces

On Tue, Aug 25, 2015 at 4:52 PM, David Ahern d...@cumulusnetworks.com wrote: The VRF driver can check the device when the enslave request happens. Will this work correctly if I set up a bonding interface or SVI, and want to put the bond-master or SVI in the vrf (but subsequently want to get,

Re: [PATCH RFC 0/5] net: L2 only interfaces

On Tue, Aug 25, 2015 at 3:50 PM, Florian Fainelli f.faine...@gmail.com wrote: Hi all, This patch series implements a L2 only interface concept which basically denies any kind of IP address configuration on these interfaces, but still allows them to be used as configuration end-points to

Re: IFLA_INET6_[ICMP6]STATS

On (09/10/15 08:43), roopa wrote: > If you decide to use a flag, there is IFLA_EXT_MASK which is used to > specify such filters from userspace today. > > /* New extended info filters for IFLA_EXT_MASK */ > #define RTEXT_FILTER_VF (1 << 0) > #define RTEXT_FILTER_BRVLAN (1 << 1) >

Re: IFLA_INET6_[ICMP6]STATS

On (09/10/15 10:13), David Miller wrote: > I don't think using such a generic netlink flag works best, the > IFLA_EXT_MASK is definitely more suitable. Ok, though this more of a IFLA_TRUNCATE_MASK than a IFLA_EXT_MASK. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the

[PATCHv2 RFC] RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats

it is desirable to avoid this if the information is not needed. This patch adds a the RTEXT_FILTER_SKIP_STATS extended info flag that can be passed with netlink_request() to avoid statistics computation for the ifinfo path. Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2:

[PATCH v3 net-next] rtnetlink: RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats

it is desirable to avoid this if the information is not needed. This patch adds a the RTEXT_FILTER_SKIP_STATS extended info flag that can be passed with netlink_request() to avoid statistics computation for the ifinfo path. Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2:

Re: [PATCHv2 RFC] RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats

On (09/12/15 00:22), Raghavendra K T wrote: > > Sowmini, Thanks for the patch which is more cleaner way without > breaking current behaviour. > > [ Though RTEXT_FILTER_NEED_STATS flag with reverse effect would have > helped immediately :)] Agree, but existing legacy usage will not set this

[PATCH RFC] RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats

it is desirable to avoid this if the information is not needed. This patch adds a the RTEXT_FILTER_SKIP_STATS extended info flag that can be passed with netlink_request() to avoid statistics comuputation for the ifinfo path. Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- inclu

[PATCH v2 net-next 2/3] RDS-TCP: Do not bloat sndbuf/rcvbuf in rds_tcp_tune

-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- net/rds/tcp.c | 16 1 files changed, 4 insertions(+), 12 deletions(-) diff --git a/net/rds/tcp.c b/net/rds/tcp.c index c42b60b..9d6ddba 100644 --- a/net/rds/tcp.c +++ b/net/rds/tcp.c @@ -67,21 +67,13 @@ void rds_tcp_n

[PATCH v2 net-next 0/3] RDS: RDS-TCP perf enhancements

socket with other parts of the kernel stack. v2: fix kbuild-test-robot warnings, comments from Sergei Shtylov and Santosh Shilimkar. Sowmini Varadhan (3): Use a single TCP socket for both send and receive. Do not bloat sndbuf/rcvbuf in rds_tcp_tune Set up MSG_MORE

[PATCH v2 net-next 1/3] RDS: Use a single TCP socket for both send and receive.

ge in rds_tcp_accept_one() has been modified to emulate the BGP state machine: the smaller IP address should back off from the connection attempt. Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2: kbuild-test-robot warning around __be32, modify subject line per Sant

[PATCH v2 net-next 3/3] RDS-TCP: Set up MSG_MORE and MSG_SENDPAGE_NOTLAST as appropriate in rds_tcp_xmit

p_sendpage() Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2: Sergei Shtylov, Santosh Shilimkar comments (some parens retained for readability) net/rds/tcp_send.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/net/rds/tcp_send.c

[PATCH net-next 2/3] RDS-TCP: Do not bloat sndbuf/rcvbuf in rds_tcp_tune

-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- net/rds/tcp.c | 16 1 files changed, 4 insertions(+), 12 deletions(-) diff --git a/net/rds/tcp.c b/net/rds/tcp.c index c42b60b..9d6ddba 100644 --- a/net/rds/tcp.c +++ b/net/rds/tcp.c @@ -67,21 +67,13 @@ void rds_tcp_n

[PATCH net-next 0/3] RDS: RDS-TCP perf enhancements

socket with other parts of the kernel stack. Sowmini Varadhan (3): Use a single TCP socket for both send and receive. Do not bloat sndbuf/rcvbuf in rds_tcp_tune Set up MSG_MORE and MSG_SENDPAGE_NOTLAST as appropriate in rds_tcp_xmit net/rds/connection.c | 22

[PATCH net-next 3/3] RDS-TCP: Set up MSG_MORE and MSG_SENDPAGE_NOTLAST as appropriate in rds_tcp_xmit

For the same reasons as 2f53384424 and 35f9c09fe9, rds_tcp_xmit may have multiple pages to send, so use the MSG_MORE and MSG_SENDPAGE_NOTLAST as hints to tcp_sendpage() Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- net/rds/tcp_send.c |8 +++- 1 files chan

[PATCH net-next 1/3] net/rds: Use a single TCP socket for both send and receive.

ge in rds_tcp_accept_one() has been modified to emulate the BGP state machine: the smaller IP address should back off from the connection attempt. Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- net/rds/connection.c | 22 ++ net/rds/rds.h|

Re: [PATCH net-next 3/3] RDS-TCP: Set up MSG_MORE and MSG_SENDPAGE_NOTLAST as appropriate in rds_tcp_xmit

On (09/30/15 08:56), santosh shilimkar wrote: > Your checkpatch.pl should have complained about commit > reference in the change-log. You might want to fix that > for consistency. It didnt. But ok, I'll fix this nit as well. -- To unsubscribe from this list: send the line "unsubscribe netdev" in

Re: [PATCH net-next 1/3] net/rds: Use a single TCP socket for both send and receive.

On (09/30/15 08:50), santosh shilimkar wrote: > > rs_tcp = (struct rds_tcp_connection *)conn->c_transport_data; > >-WARN_ON(!rs_tcp || rs_tcp->t_sock); > >+if (rs_tcp->t_sock && inet->inet_saddr < inet->inet_daddr) { > >+struct sock *nsk = new_sock->sk; > > > Any reason you

Re: [PATCH net-next 1/3] net/rds: Use a single TCP socket for both send and receive.

" or > - RDS TCP can use "RDS: TCP" or "RDS/TCP:" Ok, but in this case patch 1/3 the changes affect both core and rds-tcp modules. Working on patchv2 that will address Sergei's comments and the kbuild-test-robot warning as well > > $subject > s/net/rds:/RDS: &g

IFLA_INET6_[ICMP6]STATS

I'm doing some experiments that are trying to simultaneously scaling the number of CPUs, and the number of processes and encountering getifaddrs() weaknesses. Others have run into similar things in the past, e.g., http://lists.openwall.net/netdev/2014/01/23/119 and more relevant to my

Re: IFLA_INET6_[ICMP6]STATS

On (09/09/15 14:43), David Miller wrote: > > But what we could do is add a flag in the netlink request which > elides the stats. GLIBC et al. could then start setting the flag. > Yes, interestingly that's what I was experimenting with myself (though I was using a setsockopt in my version).

Re: [PATCH RFC 0/3] kcm: Kernel Connection Multiplexor (KCM)

On (09/21/15 15:36), Tom Herbert wrote: > segments. What we need to do, which you're probably doing for RDS, is > do message delineation on the stream as a sequence of: > > 1) Read protocol header to determine message length (BPF used here) right, that's what rds does- first reads the

[PATCH net-next] sunvnet:Invoke SET_NETDEV_DEV() to set up the vdev in vnet_new()

`ls /sys/devices/channel-devices/vnet-port-0-0/net' is missing without this change, and applications like NetworkManager are looking in sysfs for the information. Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- drivers/net/ethernet/sun/sunvnet.c | 17 +++---

Re: [PATCH RFC 0/3] kcm: Kernel Connection Multiplexor (KCM)

On (09/20/15 15:29), Tom Herbert wrote: > > Kernel Connection Multiplexor (KCM) is a facility that provides a > message based interface over TCP for generic application protocols. > The motivation for this is based on the observation that although > TCP is byte stream transport protocol with no

Re: [PATCH RFC 0/3] kcm: Kernel Connection Multiplexor (KCM)

On (09/21/15 10:33), Tom Herbert wrote: > > > > Some things that were not clear to me from the patch-set: > > > > The doc statses that we re-assemble packets the "stated length" - > > but how will the receiver know the "stated length"? > > BPF program returns the length of the next message. In my

Re: ipsec impact on performance

On (12/08/15 12:32), Steffen Klassert wrote: > > Would be nice if you could share the results. Comments are Sure, not a problem. Give me some time though, I'm also looking into the skb_cow_data and other memory-management issues that were flagged on this thread. I'll have all this info by

Re: ipsec impact on performance

On (12/02/15 12:41), David Laight wrote: > You are getting 0.7 Gbps with ass-ccm-a-128, scale the esp-null back to > that and it would use 7/18*71 = 27% of the cpu. > So 69% of the cpu in the a-128 case is probably caused by the > encryption itself. > Even if the rest of the code cost nothing

Re: [RFC] Stable interface index option

On (12/01/15 15:57), David Miller wrote: > >> > Also current versions of SNMP provide more useful information about > >> > network interface slot information in ifDescription > >> > >> Well if they do provide strings, then that is probably a better way > >> forward than messing with the kernel.

Re: ipsec impact on performance

On (12/02/15 13:07), Tom Herbert wrote: > That's easy enough to add to flow dissector, but is SPI really > intended to be used an L4 entropy value? We would need to consider the yes. To quote https://en.wikipedia.org/wiki/Security_Parameter_Index "This works like port numbers in TCP and UDP

Re: ipsec impact on performance

On (12/02/15 14:01), Tom Herbert wrote: > No, please don't persist is this myopic "we'll get to IPv6 later" > model! IPv6 is a real protocol, it has significant deployment of the > Internet, and there are now whole data centers that are IPv6 only > (e.g. FB), and there are plenty of use cases of

Re: ipsec impact on performance

On (12/02/15 13:44), Tom Herbert wrote: > > IPv6 would be an interesting academic exercise, but it's going > > to be a while before we get RDS-TCP to go over IPv6. > > > Huh? Who said anything about RDS-TCP? I thought you were trying to > improve IPsec performance... yes, and it would be nice to

Re: ipsec impact on performance

On (12/03/15 09:45), Steffen Klassert wrote: > pcrypt(echainiv(authenc(hmac(sha1-ssse3),cbc-aes-aesni))) > > Result: > > iperf -c 10.0.0.12 -t 60 > > Client connecting to 10.0.0.12, TCP port 5001 > TCP window size: 45.0 KByte (default)

[PATCH RESEND v7] i40e: Look up MAC address in Open Firmware or IDPROM

;martin.peter...@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2, v3: Andy Shevchenko comments v4: Shannon Nelson review: explicitly set up mac filters before register_netdev v5: Shannon Nelson code style comments v6: Shannon Nelson code style comments v7: Ensure

  1   2   3   4   5   6   7   >