und 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
s 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
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
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 netdev"
F_MAC flag 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 <martin.peter...@oracle.com>
Signed-off-by: Sowmini Varadha
d 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
--
To unsubscribe from this list: send the line
F_MAC flag 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 <martin.peter...@oracle.com>
Signed-off-by: Sowmini Varadha
;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
_mac field 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 <martin.peter...@oracle.com>
Signed-off-by: Sowmini Varadha
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
mode)
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
in i40e_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
P 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 from this list: se
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
et.
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 more ipsec-fr
provide 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
--
To unsu
d 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
es, 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 majord...@v
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
e 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
e, 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
More majordo
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
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: send the line &quo
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: send the line &qu
ilable),
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 <sowmini.varad...@oracle.com>
---
include/linux/skbuff.h
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 message
t 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 this list: send the lin
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 this l
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
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
nneling 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 rds-tcp made
sense for us at t
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
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 "unsubscribe netd
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: send t
ata 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 that Solaris KSSL took, back
fic 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 send the data? Any estimates f
ist. 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: se
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 tryi
re 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 uncommon).
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
Or update ixgbe/i40e to use
this 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 <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
i40e_stat_str(>back->hw, ret),
> > +i40e_aq_str(>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 <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
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
ntly, 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
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
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
>
ut 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.
--Sowmini
; 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 opportunistically f
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 <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
. 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
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 just call the i40e_s
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
entually 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
. 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
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
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
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 message
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, w
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
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
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
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
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
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 list: send
ot, 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" in
the body of a
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
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,
lag
make it Do The Right 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
-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
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
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
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
-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
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
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
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|
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
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
" 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
s 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 the
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
--
To
ther 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
`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 +++---
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:
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
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
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
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:
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
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
n 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
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
, say, timestamp/other-stats from the L2 slave in the vrf?)
--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
router, after unwinding
existing config as needed)
I'm assuming something will prevent an L2-only interface from being
part of a vrf.
--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
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 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
501 - 600 of 629 matches
Mail list logo
