On (12/30/15 15:42), Stas Sergeev wrote:
> 29.12.2015 18:22, Sowmini Varadhan пишет:
> > Do you have admin control over the ubuntu router?
> > If yes, you might want to check the shared_media [#] setting
> > on that router for the interfaces with overlapping subnets.
> &
IPSKB_DOREDIRECT if shared_media is turned off.
--Sowmini
[#] https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/theconfvariables.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
he router. I
suppose it might not hurt if the receiver can do some sanity checking
on the redirect but this might not eliminate every error, since
it might not be possible to detect netmask mismatch in every case.
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netde
u would have to check into the configuration
and/or implementation of the router- it should not be sending
back a redirect in the above case (different netmasks) even
if the ingress and egress physical interfaces are the same.
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe
a bug
for checksumming here..
if you have multiple encapsulations above (vxlan over vxlan?)
I think lot of other things like pmtu may also be broken? (Each
encaps layer lowers the actual application mtu till the thing starts
to get absurd)
--Sowmini
--
To unsubscribe from this list: send
all this info by netdev, at the latest.
--Sowmini
--
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
lag in the platform-private i40e_pf structure
tracks whether a platform-specific mac address was found, in which
case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan()
will be triggered.
Reviewed-by: Martin K. Petersen
Signed-off-by: Sowmini Varadhan
---
v2, v3: Andy Shevchenko comments
v
n topic, please let me know.
As I've already mentioned, I'm interested.
BTW, a related topic may be this one:
http://www.netdevconf.org/1.1/talk-securing-traffic-tunnelled-over-l3-sowmini-varadhan.html
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe ne
On (12/07/15 09:40), Steffen Klassert wrote:
>
> I've pushed it to
>
> https://git.kernel.org/cgit/linux/kernel/git/klassert/linux-stk.git/log/?h=net-next-ipsec-offload
>
> It is just example code, nothing that I would show usually.
> But you asked for it, so here is it :)
that's fine, I dont e
CONFIG_OF either), and kbuild-test-robot
did not catch that either, afaict. Perhaps you are missing some
include files?
Without the dp definition, of_get_mac_address() further below
will not find a "dp".
Rest of the comments are addressed in v8 that I just sent out.
--Sowmini
-
lag in the platform-private i40e_pf structure
tracks whether a platform-specific mac address was found, in which
case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan()
will be triggered.
Reviewed-by: Martin K. Petersen
Signed-off-by: Sowmini Varadhan
---
v2, v3: Andy Shevchenko comments
v
ned-off-by: Sowmini Varadhan
---
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 that i40e_macaddr_init() is called only for VSI_MAIN, and only
eld in the platform-private i40e_pf structure
tracks whether the mac address was default or not, and in the latter
case, will trigger the calls to i40e_aq_mac_address_write() and
i40e_aq_add_macvlan().
Reviewed-by: Martin K. Petersen
Signed-off-by: Sowmini Varadhan
---
v2, v3: Andy Shevchenko c
On (12/03/15 13:35), Jeff Kirsher wrote:
>
> I will drop your current patch in my next-queue tree (dev-queue branch)
> and will await an updated patch.
sounds good. Let me work with Shannon and Andrew to make sure
we cover all cases.
--Sowmini
--
To unsubscribe from this list: send
're copying every TCP data frame.
>
> If this is the case, even with GSO/whatever offloads, I expect that
> performance will be roughly halfed.
The other obvious "low-hanging fruit" is to address the TODO in the
comment above esp_alloc_tmp.
--Sowmini
--
To unsubscribe f
On (12/03/15 16:53), Bowers, AndrewX wrote:
>
> I get an error -11 on driver init with this patch applied, I can
> revert it and everything works normally. Dmesg screenshot is attached,
> can supply complete dmesg log if needed.
Yes, that's the same thing that I'm running into as well.
Using th
0e_hw that
need to be taken into account for the second version)
In order to send a fix out for review, what should I clone?
should I just apply the patch/540218 to net-next and send the update?
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of
formatios as soon as the code is available.
that's pretty good compared to the baseline.
I'd like to try out our patches, when they are ready.
I think you may get some more improvement if you manually pin the irq
and iperf to specific cpus (at least that was my observation for transp
_ALIGN very well, and I dont think this is the most wholesome
thing for perf.
--Sowmini
--
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
yes, and it would be nice to find out that IPsec for IPv6 is
fast, but I'm afraid there are a lot of IPv4 use cases out there that
need the same thing for IPv4 too (first?).
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to m
rovide a good L4 hash
> for RPS/RFS, it would be interesting to see what the effects are with
> IPsec processing. (ESP/UDP could also if RSS/ECMP is critical)
IPv6 would be an interesting academic exercise, but it's going
to be a while before we get RDS-TCP to go over IPv6.
--Sowmini
bounds
yet.
I think a lot of the manual tweaking of irq/process placement
is needed because the existing rps/rfs flow steering is looking
for TCP/UDP flow numbers to do the steering. It can just as easily
use the IPsec SPI numbers to do this, and that's another place where
we can make this
thing to me, and one of the
things I was going to try out later today is to instrument the
effects of pinning irqs and iperf threads to a specific cpu.
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
Mo
t; One way to get a view of the cost of the encryption (and copies)
> is to do the operation twice.
I could also just instrument it with perf tracepoints, if that
data is interesting
--Sowmini
--
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
re is enough interest and
> maybe some additional topics.
Sounds like an excellent idea. I'm certainly interested.
--Sowmini
>
--
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
really need to compare this to GSO/GRO
for a pure-s/w, apples-apples comparison.
> Bumping the MTU to 9000:
Yes that's not always an option. See also the comments from Eric/Rick
about latency [http://lists.openwall.net/netdev/2015/11/24/111].
--Sowmini
--
To unsubscribe from this list: s
c APIs send - the immutable or the mutable index?" so it
was ok for them to have the complexity of two interface indices.
--Sowmini
--
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
er, I can still get about 6 Gbps for clear traffic.
Thus if I could get closer to 6 Gbps for my patch, I'd at least
know that it was just GRO that was missing.. but I'm only getting
3 Gbps, which makes me think I missed something else on the sender
itself.
--Sowmini
--
To unsubscribe from
e the
> per-packet costs while keeping the per-byte roughly the same.
actually the hack/rfc I sent out does help (in that it almost
doubles the existing 1.8 Gbps). Problem is that this cliff is much
steeper than that, and there's more hidden somewhere.
--Sowmini
--
To unsubscribe from th
close
as possible to GSO/GRO, the rest will follow closely behind.
So is my patch in the right direction? Anything obvious I am missing?
I'd like to budge that number beyond 3 Gbps :-)
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
tcp segment is available),
set things up for xfrm_output_one and trigger the esp_output
A 1-bit hole in sk_buff is used to track an skb that needs xfrm (might
not need to burn that bit, but using it for now)
Signed-off-by: Sowmini Varadhan
---
include/linux/skbuff.h |6
lloc/free of the
"tmp" buffer.
But these are all still relatively small things - tweaking them
doesnt get me significantly past the 3 Gbps limit. Any suggestions
on how to make this budge (or design criticism of the patch) would
be welcome.
--Sowmini
--
To unsubscribe from this list:
an they use it back with existing
ifioctl and other calls? i.e., API compat will have some rough edges.
--Sowmini
--
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
On (12/01/15 13:04), Maximilian Wilhelm wrote:
>
> The reason we would like to have those is quite simple: As we operate
> a somewhat larger network we would like to monitor it accordingly and
> see when links get saturated etc. Therefore we used snmp based
> solutions and the net-snmp daemon on a
tiple RDS sockets funneling to a single tcp connection, sharing
a single congestion state-machine.
I dont know if this is a "poorly designed application", I'm sure
its not perfect, but we have a ton of Oracle clustering s/w that's
already doing this with IB, so extending this with
be send out on the wire.
>
> Since processors provide aesni and other crypto extensions as part of
> their instruction set architecture, this, of course, does not make sense
> any more.
BTW, that, exactly, was what happened to Solaris kssl.
--Sowmini
--
To unsubscribe from
l try to
put all my data together for this for netdev 1.1.
> > E.g., if I get a cipher-suite request outside the aes-ni, what would
> > happen (punt to uspace?)
> >
> > --Sowmini
>
> Right, bind() would fail and you would fallback to uspace.
That's the approach
concern is that this patchset provides a solution for the "80%"
case but what about the other 20% (and the non x86 platforms)?
E.g., if I get a cipher-suite request outside the aes-ni, what would
happen (punt to uspace?)
--Sowmini
--
To unsubscribe from this list: send the line "u
y (in any manner that it wants)
and set it on the PF_KCM socket, then use that key to encrypt application
data just before passing it off to tcp. (Of course, then you have to deal
with the fact that BPF still needs to get to the clear data somehow)
--Sowmini
--
To unsubscribe from this list: s
the fraglist. It might be interesting if
> there was an interface to send skbufs on a kernel socket.
yes. Or if there was a way to factor out the non-zero page-order
enhancements in skb_page_frag_refill in a way that they could be
shared with RDS.
--Sowmini
--
To unsubscribe from this list:
overcome first for the specific req-resp
patterns that are common in DB workloads)
The other question I had when reading this code is: what if the
application never sends that last MSG_BATCH-less message, e.g.,
it lies about how its going send more messages? will something eventually
time-out and s
at there
are more issues (mtu reduction etc) with nested encapsulation,
and this is actually applicable even without the recursion issue
(i.e even if you dont have a tunnelling loop, and even if it
is not ipv6, there are some non-trivial problems here. Luckily,
nested encaps is somewhat uncom
sal, except that "ttl" has other meanings in other contexts, so
a bit non-intuitive)
--Sowmini
(fwiw, RFC 2473 proposes an ipv6 option to track nested encapsulation,
and that never took off, because, among other reasons, its hard to
offload such options to hardware. Anyway, you are not
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
his later, after this goes in?
--Sowmini
--
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
. Petersen
Signed-off-by: Sowmini Varadhan
---
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
drivers/net/ethernet/intel/i40e/i40e_mai
n",
> > + i40e_stat_str(&vsi->back->hw, ret),
> > +i40e_aq_str(&vsi->back->hw, aq_err));
> > + }
> > + return ret;
> Same about kernel doc.
See earlier response.
--Sowmini
--
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
. Petersen
Signed-off-by: Sowmini Varadhan
---
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/i40e/i40e_main.c | 84 ++-
1 files changed, 83
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 stu
To frame the question differently, where all should I be invoking
the new i40e_macaddr_init() function from?
--Sowmini
--
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
without vlans.
I assume you mean .1q (aka linux macvlan) as opposed to access/trunk vlans?
I will test that tomorrow but I did a quick sanity check on mtu, as well
as turning tso on/off which also restarts the driver (I believe), and
it was "fine", i.e., able to ping offlink hosts.
--Sowm
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
Signed-off-by: Sowmini Varadhan
---
v2
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
>
to look
> at section 4.2.1.5.3 of the XL710 data sheet in order to know how to
> use i40e_aq_mac_address_write() for your situation.
ok. I'll look into it (and also why this did not show up in my testing).
fwiw, the ixgbe patch is quite clearly missing in i40e, and hopefully
we wont be
uld be useful here.
But both in this case, and for the ixgbe template on which I tried
to model this, the OF/idprom probing happens from the ->probe when the
driver comes up, and ndo_set_mac_address is not involved.
I dont know if it is easier (or even feasible to do this from ->probe)
to
eventually call the ndo_set_mac_address call so the HW
> knows to use a different mac address?
yes, and here I was hoping for some feedback from the intel folks as
well. Commit c762dff24c06 sets hw->mac.perm_addr. I dont know
if there is some similar i40e state that needs to be set.
Please
e \n nits, I'm going to pass on those.
Thanks for reviewing.
--Sowmini
--
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
. Petersen
Signed-off-by: Sowmini Varadhan
---
v2: andy shevchenko comments
v3: more andy shevchenko comments
drivers/net/ethernet/intel/i40e/i40e_common.c | 30 +
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
. Petersen
Signed-off-by: Sowmini Varadhan
---
v2: review comments from Andy Shevchenko
drivers/net/ethernet/intel/i40e/i40e_common.c | 32 +
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
b/drivers/net/ethe
addr = of_get_mac_address(dp);
>
> ^^^
I was not able to find any.
I'm fixing up the rest and respinning V2 as a separate thread.
Thanks
--Sowmini
--
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
. Petersen
Signed-off-by: Sowmini Varadhan
---
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_common.c
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 2d74c6
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
---
net/rds/tcp_recv.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions
d, 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
---
v2: review comment from thread: cann
e way to access unaligned data,
> and that is with the get_unaligned() and put_unaligned() helpers.
ok. I'll fix it up to use the *_unaligned functions and resend this
out later today.
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
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
aligned to 8 on 64-bit.
>
> Without your patch I get the correct notification when deleting a SA:
>
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?
(and openswan/pluto dont flag any errors with the patch, which
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
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
---
net/xfrm/xfrm_
alignment values into consideration when doing kzalloc()
Signed-off-by: Sowmini Varadhan
---
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/asymmetric_keys/x509_public_key.c
ind
transport like IB.
Acked-by: Sowmini Varadhan
--
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
explaining
that the 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
nd if it does not, why not? The only
difference (in theory) is whether you do encryption before, or after,
adding the transport (tcp/udp) header, so if there is a big perf gap,
we need to understand why.
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" i
because of the many-to-one dgram-over-stream
hybrid.
I've looked at IPSEC/IKE in transport mode for RDS on the kernel tcp
socket as we discussed at Plumbers in August, and that has some costs..
would be interesting to evaluate against other options..
--Sowmini
--
To unsubscribe from this
s 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
---
net/rds/tcp_l
terfaces.
Signed-off-by: Sowmini Varadhan
---
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,14 @@ int rds_bind(struct sock
Thing per rfc 3484?
--Sowmini
--
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
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
---
v2: kbuild-test-robot warning around __be32, modify subject line per
Santosh Shilimkar
p_sendpage()
Signed-off-by: Sowmini Varadhan
---
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 b/net/rds/tcp_send.c
index 53b17ca..2894
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 and
-by: Sowmini Varadhan
---
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_nonagle(struct socket *sock
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
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
" 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:/RD
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
---
net/rds/tcp_send.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff
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
---
net/rds/connection.c | 22 ++
net/rds/rds.h|4 +++-
net/rds/tcp_listen.c | 1
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
-by: Sowmini Varadhan
---
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_nonagle(struct socket *sock
first reads the sizeof(rds_header),
and from that, figures out payload len, to stitch each rds dgram
together from intermediate tcp segments..
> 2) Read data up to the length of the message
> 3) Deliver message
> 4) Goto #1 (i.e. process next message in the stream).
Thanks for the rest of t
rather than overloading accept().. feels like that would
keep the semantics cleaner, and probably less likely to trip
up on accept code in the kernel..
--Sowmini
--
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
r this using network
namespaces to define bundles of outgoing interfaces, but that solution
may not always be workable for other use-cases. Thus it might actually
be more obvious to simply use tcp sockets (and use something like XDR
for message boundary markers on the stream).
--Sowmini
`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
---
drivers/net/ethernet/sun/sunvnet.c | 17 +++--
1 files changed, 11 inser
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
---
v2: David Miller comments: pass u32
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
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
---
v2: David Miller comments: pass u32
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
---
include/net/rtnetlink.h|3
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 b
ILTER_BRVLAN (1 << 1)
> #define RTEXT_FILTER_BRVLAN_COMPRESSED (1 << 2)
I was actually going to use a NLM_F* flag, which is what
I thought Dave as suggesting (seems a bit simpler
than IFLA_EXT_MASK).
--Sowmini
--
To unsubscribe from this list: send the line "unsubscrib
opt in my version). I'll send out
a patch rfc later this week for this.
--Sowmini
--
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
users in glibc,
and google did not find any usage.
--Sowmini
--
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
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
---
net/rds/connection.c |9 +
1 files
501 - 600 of 633 matches
Mail list logo
