On 20/05/2015 03:49, Hefty, Sean wrote:
>>> I wonder if the existing ib_cm interface is even what we want.
>>> Currently, the rdma_cm pushes the private data (i.e. IP address)
>>> comparison into the ib_cm. This is only used by the rdma_cm.
>>> Should that instead be moved out of the ib_cm and han
On 21/05/2015 08:48, Or Gerlitz wrote:
> On Thu, May 21, 2015 at 8:33 AM, Haggai Eran wrote:
>> On 20/05/2015 02:55, Jason Gunthorpe wrote:
>>> On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote:
> From: Guy Shapiro
>
> Implement the get_net_device_by_port_pkey_ip callback th
On 20/05/2015 02:55, Jason Gunthorpe wrote:
> On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote:
>> For each ipoib device we iterate through all upper devices when searching
>> for a matching IP, in order to support bonding.
>
> Checking an IP address in a packet against a device without
On Thu, May 21, 2015 at 8:33 AM, Haggai Eran wrote:
> On 20/05/2015 02:55, Jason Gunthorpe wrote:
>> On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote:
>>> > From: Guy Shapiro
>>> >
>>> > Implement the get_net_device_by_port_pkey_ip callback that returns network
>>> > device to ib_core
On Tue, May 19, 2015 at 1:28 PM, David Miller wrote:
> From: Andy Gospodarek
> Date: Tue, 19 May 2015 15:47:32 -0400
>
>> Are you actually saying that if users complain loudly enough about
>> the current behavior (not the change Roopa has proposed) that you
>> would be open to considering a chang
On 20/05/2015 02:55, Jason Gunthorpe wrote:
> On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote:
>> > From: Guy Shapiro
>> >
>> > Implement the get_net_device_by_port_pkey_ip callback that returns network
>> > device to ib_core according to connection parameters. Check the ipoib
>> > de
From: Scott Feldman
In review of Simon's patchset "rocker: transaction fixes". it was noted
that rocker->neigh_tbl_next_index was unprotected in the call path below
and could race with other contexts calling rocker_port_ipv4_neigh():
arp_process()
neigh_update()
rocker_ne
I'm pushing 10,000 frames per second of UDP traffic through a Linux
system with a bridge configured between two 1GbE ports.
Iptables is installed and running, but the default rule is ACCEPT with
no other rules.
When I make the packets 1179 bytes in size (total size includes
Ethernet header, etc.)
At Wed, 20 May 2015 16:42:44 -0700,
Laura Abbott wrote:
>
> On 05/20/2015 05:44 AM, Takashi Iwai wrote:
> > At Wed, 20 May 2015 11:46:31 +0200,
> > Marcel Holtmann wrote:
> >>
> >> Hi Oliver,
> >>
> The data is cached in RAM. More specifically, the former loaded
> firmware files are rel
> > -Original Message-
> > From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
> > Sent: Tuesday, May 19, 2015 5:06 PM
> > To: Kirsher, Jeffrey T; intel-wired-...@lists.osuosl.org
> > Cc: Skidmore, Donald C; Or Gerlitz; David Miller; Linux Netdev List;
> > nhor...@redhat.com; sassm..
On Thu, May 21, 2015 at 04:59:22AM +0200, Linus Lüssing wrote:
>
> * For i=br_multicast_init(), e=br_multicast_enable() and
> s=br_multicast_stop() is the order i->e->s->e->s->e->... always
> ensured by the netdev API? Will this work even if I have
br_multicast_init always happens first obvio
rocker_port_ipv4_nh() and in turn rocker_port_ipv4_neigh() may be
be called with trans == SWITCHDEV_TRANS_PREPARE and then
trans == SWITCHDEV_TRANS_COMMIT from switchdev_port_obj_set() via
fib_table_insert().
The first time that rocker_port_ipv4_nh() is called, with
trans == SWITCHDEV_TRANS_PREPAR
rocker_port_fdb_flush() is called by rocker_port_stp_update() which in
turn may be called with trans == SWITCHDEV_TRANS_PREPARE and then
trans == SWITCHDEV_TRANS_COMMIT from switchdev_port_attr_set() via
br_set_state().
When rocker_port_fdb_flush() is called with trans == SWITCHDEV_TRANS_PREPARE
i
rocker_port_fdb_flush() may be called be called with
trans == SWITCHDEV_TRANS_PREPARE and then trans == SWITCHDEV_TRANS_COMMIT from
switchdev_port_attr_set() via switchdev_port_obj_add().
Adding the new entry to the FDB table when trans == SWITCHDEV_TRANS_PREPARE
may result in a memory leak becaus
The motivation for this is that rocker_port_internal_vlan_id_{get,put} appear
to only partially implement the transaction model: memory allocation
and freeing is transactional, but hash and bitmap manipulation is not.
The latter could be fixed, however, as it is not currently exercised
due to tran
Hi,
this series addresses what appear to be errors in the handling of
prepare and then commit transactions in the rocker driver.
In all cases the problem is that data structures visible outside of
the transaction are modified during the prepare phase.
In the case of the first two patches this re
Hi Alen,
Thank you for your comment.
> 1. This driver probably belongs somewhere in drivers/net rather
> than platform-x86
I was devided between drivers/net and platform-x86...
> 2. It would be helpful to undertand what the use case is. You describe it
> as
I know. Unfortunately curren
2015-05-20 19:59 GMT-07:00 Stephen Rothwell :
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/phy/phy.c between commit c15e10e71ce3 ("net: phy: Make sure
> phy_start() always re-enables the phy interrupts") from the net tree
> and commit 3e2186e02112 ("ne
Dear Darren, Alex,
Thanks for your comments. I'll appreciate your help.
I'll resend new patchset to be updated according to your comments.
Sincerely,
Taku Izumi
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Wednesday, May 20, 2015 11:47 PM
> To
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/phy.c between commit c15e10e71ce3 ("net: phy: Make sure
phy_start() always re-enables the phy interrupts") from the net tree
and commit 3e2186e02112 ("net: phy: Add state machine state transitions
debug prints"
Network managers like netifd (used in OpenWRT for instance) try to
configure interface options after creation but before setting the
interface up.
Unfortunately the sysfs / bridge currently only allows to configure the
hash_max and multicast_router options when the bridge interface is up.
But sinc
On Wed, 2015-05-20 at 18:59 -0700, Cong Wang wrote:
> On Wed, May 20, 2015 at 6:53 PM, Eric Dumazet wrote:
> >
> > Listen Cong, could you please stop assuming that I am a jerk ?
>
> It is at least the second time to tell you: you SHOULD direct my email
> to /dev/null, SERIOUSLY, I have no interes
On 05/19/2015 11:32 PM, Steffen Klassert wrote:
On Tue, May 19, 2015 at 11:32:15AM -0700, Alexander Duyck wrote:
On 05/19/2015 12:57 AM, Steffen Klassert wrote:
The MTU should be 1500. All the IPsec overhead is handled by PMTU
discovery, just like in the case we use IPsec without vti tunnels.
T
On Wed, May 20, 2015 at 6:53 PM, Eric Dumazet wrote:
>
> Listen Cong, could you please stop assuming that I am a jerk ?
It is at least the second time to tell you: you SHOULD direct my email
to /dev/null, SERIOUSLY, I have no interest to argue any stupid thing
like this with you, PERIOD.
Since y
On Wed, 2015-05-20 at 18:47 -0700, Cong Wang wrote:
> On Wed, May 20, 2015 at 5:30 PM, Eric Dumazet wrote:
> > On Wed, 2015-05-20 at 16:46 -0700, Cong Wang wrote:
> >
> >> There is very little to do on ingress side since there is no queue at all,
> >> not to mention priority, you could try ifb to
On Wed, May 20, 2015 at 5:30 PM, Eric Dumazet wrote:
> On Wed, 2015-05-20 at 16:46 -0700, Cong Wang wrote:
>
>> There is very little to do on ingress side since there is no queue at all,
>> not to mention priority, you could try ifb to see if it fits your need.
>
> Note that if the need is to poli
On Wed, 2015-05-20 at 17:48 -0700, Rick Jones wrote:
> On 05/20/2015 05:37 PM, Eric Dumazet wrote:
>
> > Anyway, if we can send tcp data at 100Gbits on one flow, I guess we are
> > doing a terrific job and do not need to tweak TCP stack anymore ;)
>
> :)
>
Note that I have no particular strong
On 05/20/2015 05:37 PM, Eric Dumazet wrote:
Anyway, if we can send tcp data at 100Gbits on one flow, I guess we are
doing a terrific job and do not need to tweak TCP stack anymore ;)
:)
rick
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to major
On Wed, 2015-05-20 at 17:06 -0700, Rick Jones wrote:
> On 05/20/2015 04:35 PM, Eric Dumazet wrote:
> > From: Marcelo Ricardo Leitner
> >
> > This patch tracks the total number of inbound and outbound segments on a
> > TCP socket. One may use this number to have an idea on connection
> > quality wh
On Thu, 2015-05-21 at 01:53 +0200, Thomas Graf wrote:
> On 05/15/15 at 08:06am, Herbert Xu wrote:
> > On Thu, May 14, 2015 at 07:37:56AM -0700, Eric Dumazet wrote:
> > >
> > > This solves the corruption thanks Herbert.
> >
> > Great.
> >
> > > But wasn't rhashtable meant to be faster ? ;)
> >
>
On Wed, 2015-05-20 at 16:46 -0700, Cong Wang wrote:
> There is very little to do on ingress side since there is no queue at all,
> not to mention priority, you could try ifb to see if it fits your need.
Note that if the need is to police traffic, ifb is not really needed :
TC="tc"
DEV="dev eth0"
Jamal points out that this header also contains kernel internal magic that
cannot be used from userspace for anything meaningful.
Lets remove what the kernel doesn't use anymore and wrap remainder with
__KERNEL__.
Suggested-by: Jamal Hadi Salim
Suggested-by: Alexei Starovoitov
Signed-off-by: Fl
On 05/20/2015 04:35 PM, Eric Dumazet wrote:
From: Marcelo Ricardo Leitner
This patch tracks the total number of inbound and outbound segments on a
TCP socket. One may use this number to have an idea on connection
quality when compared against the retransmissions.
RFC4898 named these : tcpEStat
On Wed, May 20, 2015 at 3:32 PM, Simon Horman
wrote:
>
> On Wed, May 20, 2015 at 10:37:52AM -0700, Scott Feldman wrote:
> > On Wed, May 20, 2015 at 5:57 AM, Simon Horman
> > wrote:
> > > On Wed, May 20, 2015 at 01:17:36PM +0200, Jiri Pirko wrote:
> > >> Wed, May 20, 2015 at 10:46:26AM CEST, simon
On Thu, May 21, 2015, at 01:50, Eric Dumazet wrote:
> On Wed, 2015-05-20 at 17:35 +0200, Hannes Frederic Sowa wrote:
>
> > +
> > +static int unix_stream_splice_actor(struct sk_buff *skb,
> > + int skip, int chunk,
> > + struct unix_stream
On Thu, May 21, 2015, at 00:25, Florian Westphal wrote:
> ip -6 addr add dead::1/128 dev eth0
> sleep 5
> ip -6 route add default via dead::1/128
> -> fails
> ip -6 addr add dead::1/128 dev eth0
> ip -6 route add default via dead::1/128
> -> succeeds
>
> reason is that if (nonsensensical) route ab
On 05/15/15 at 08:06am, Herbert Xu wrote:
> On Thu, May 14, 2015 at 07:37:56AM -0700, Eric Dumazet wrote:
> >
> > This solves the corruption thanks Herbert.
>
> Great.
>
> > But wasn't rhashtable meant to be faster ? ;)
>
> Is it, that's news to me :)
Eric, can you share the scripts you used to
On Wed, 2015-05-20 at 17:35 +0200, Hannes Frederic Sowa wrote:
> +
> +static int unix_stream_splice_actor(struct sk_buff *skb,
> + int skip, int chunk,
> + struct unix_stream_read_state *state)
> +{
> + return skb_splice_bits(skb,
On Thu, May 21, 2015, at 01:21, Eric Dumazet wrote:
> On Wed, 2015-05-20 at 17:35 +0200, Hannes Frederic Sowa wrote:
> > This patch implements sendpage support for AF_UNIX SOCK_STREAM
> > +
> > + if (newskb)
> > + skb_queue_tail(&other->sk_receive_queue, newskb);
>
> Are you sure we ne
(Cc'ing Jamal)
On Tue, May 19, 2015 at 2:11 PM, Uwe Kleine-König
wrote:
> Hello,
>
> I hope this is the/a right list to ask this question. If not, I'd be
> happy to learn the right alternative.
>
> For a system that implements the Media Redundancy Protocol (MRP,
> http://en.wikipedia.org/wiki/Med
On Wed, 2015-05-20 at 17:35 +0200, Hannes Frederic Sowa wrote:
> Prepare skb_splice_bits to be able to deal with AF_UNIX sockets.
>
> AF_UNIX sockets don't use lock_sock/release_sock and thus we have to
> use a callback to make the locking and unlocking configureable.
>
> Signed-off-by: Hannes Fr
On 05/20/2015 05:44 AM, Takashi Iwai wrote:
At Wed, 20 May 2015 11:46:31 +0200,
Marcel Holtmann wrote:
Hi Oliver,
The data is cached in RAM. More specifically, the former loaded
firmware files are reloaded and saved at suspend for each device
object. See fw_pm_notify() in firmware_class.c.
From: Marcelo Ricardo Leitner
This patch tracks the total number of inbound and outbound segments on a
TCP socket. One may use this number to have an idea on connection
quality when compared against the retransmissions.
RFC4898 named these : tcpEStatsPerfSegsIn and tcpEStatsPerfSegsOut
These ar
On Wed, May 20, 2015 at 2:10 PM, Alex Gartrell wrote:
> Hey everyone,
>
> tl;dr; pure python generic netlink library with simple clients for ipvs and
> taskstats here: https://github.com/facebook/gnlpy
libnl should have python support for generic netlink too:
$ ls python/netlink/genl/
capi.i __
On Wed, 2015-05-20 at 17:35 +0200, Hannes Frederic Sowa wrote:
> This patch implements sendpage support for AF_UNIX SOCK_STREAM
> sockets. This is also required for a complete splice implementation.
>
> The implementation is a bit tricky because we append to already existing
> skbs and so have to
>
>30 usecs (or really, 1 jiffy) can go by pretty fast.
>
>Move the set of the timeout immediately before the loop.
>
>Remove the unnecessary max(1ul, usecs_to_jiffies(30)) as
>usecs_to_jiffies with a non-zero constant is guaranteed
>to be non-zero.
>
>Signed-off-by: Joe Perches
>---
> drivers/net
v3 -> v4:
- Patch 8 is new. It keeps track of the DST_NOCACHE routes in a list to handle
the iface down/unregister event.
- Remove rcu from the newly added rt6i_pcpu variable. It is not needed
because it has already been protected by the existing reader/writer lock.
- Thanks to 'Julian Anast
This patch always creates RTF_CACHE clone with DST_NOCACHE
when FLOWI_FLAG_KNOWN_NH is set so that the rt6i_dst is set to
the fl6->daddr.
Signed-off-by: Martin KaFai Lau
Acked-by: Julian Anastasov
Tested-by: Julian Anastasov
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
---
include/net/ip6_f
A prep work for creating RTF_CACHE on exception only. After this
patch, the same condition (rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY))
is checked twice. This redundancy will be removed in the later patch.
Signed-off-by: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
Cc: Ju
This patch removes the assumptions that the returned rt is always
a RTF_CACHE entry with the rt6i_dst and rt6i_src containing the
destination and source address. The dst and src can be recovered from
the calling site.
We may consider to rename (rt6i_dst, rt6i_src) to
(rt6i_key_dst, rt6i_key_src)
On 05/20/2015 04:04 PM, Andy Gospodarek wrote:
Well I can now delete most of my initial response. :)
Overall I would say this is really cool functionality. Even if you do
not want it merged, I think it is great that you shared it with the
community this way. I got a chance to look at is a bi
Instead of doing the rt6->rt6i_node check whenever we need
to get the route's cookie. Refactor it into rt6_get_cookie().
It is a prep work to handle FLOWI_FLAG_KNOWN_NH and also
percpu rt6_info later.
Signed-off-by: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
Cc: Julian Anas
When creating a RTF_CACHE route, RTF_ANYCAST is set based on rt6i_dst.
Also, rt6i_gateway is always set to the nexthop while the nexthop
could be a gateway or the rt6i_dst.addr.
After removing the rt6i_dst and rt6i_src dependency in the last patch,
we also need to stop the caller from depending on
The neighbor look-up used to depend on the rt6i_gateway (if
there is a gateway) or the rt6i_dst (if it is a RTF_CACHE clone)
as the nexthop address. Note that rt6i_dst is set to fl6->daddr
for the RTF_CACHE clone where fl6->daddr is the one used to do
the route look-up.
Now, we only create RTF_CA
After the patch
'ipv6: Only create RTF_CACHE routes after encountering pmtu exception',
we need to compensate the performance hit (bouncing dst->__refcnt).
Signed-off-by: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
Cc: Julian Anastasov
---
include/net/ip6_fib.h |
This patch creates a RTF_CACHE routes only after encountering a pmtu
exception.
After ip6_rt_update_pmtu() has inserted the RTF_CACHE route to the fib6
tree, the rt->rt6i_node->fn_sernum is bumped which will fail the
ip6_dst_check() and trigger a relookup.
Signed-off-by: Martin KaFai Lau
Cc: Han
This patch breaks up ip6_rt_copy() into ip6_rt_copy_init() and
ip6_rt_cache_alloc().
In the later patch, we need to create a percpu rt6_info copy. Hence,
refactor the common rt6_info init codes to ip6_rt_copy_init().
Signed-off-by: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
This patch keeps track of the DST_NOCACHE routes in a list and replaces its
dev with loopback during the iface down/unregister event.
Signed-off-by: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
Cc: Julian Anastasov
---
include/net/ip6_fib.h | 3 ++
net/ipv6/route.c | 7
On 05/20/2015 01:45 PM, Jay Vosburgh wrote:
Michal Kubecek wrote:
On Tue, May 19, 2015 at 04:29:45AM -0400, Patrick Simmons wrote:
On 05/19/2015 03:49 AM, Michal Kubecek wrote:
On Tue, May 19, 2015 at 02:09:43AM -0400, Patrick Simmons wrote:
I've written a new mode for the kernel bonding d
On Wed, May 20, 2015 at 10:37:52AM -0700, Scott Feldman wrote:
> On Wed, May 20, 2015 at 5:57 AM, Simon Horman
> wrote:
> > On Wed, May 20, 2015 at 01:17:36PM +0200, Jiri Pirko wrote:
> >> Wed, May 20, 2015 at 10:46:26AM CEST, simon.hor...@netronome.com wrote:
> >> >On Wed, May 20, 2015 at 05:36:0
ip -6 addr add dead::1/128 dev eth0
sleep 5
ip -6 route add default via dead::1/128
-> fails
ip -6 addr add dead::1/128 dev eth0
ip -6 route add default via dead::1/128
-> succeeds
reason is that if (nonsensensical) route above is added,
dead::1 is still subject to DAD, so the route lookup will
pi
This patch series introduce support for _CCA object, which is currently
used mainly by ARM64 platform to specify DMA coherency attribute for
devices when booting with ACPI.
A copy of ACPIv6 can be found here:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
This patch also intro
>From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
object to be specified for DMA-cabpable devices. Therefore, this patch
specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is mi
This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.
The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops()
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
This patch simplifies this process by introducing a new device
property API, device_dma_is_coherent(), which calls th
Currently, the driver has separate logic to determine device coherency
for DT vs ACPI. This patch simplifies the code with a call to
device_dma_is_coherent().
Signed-off-by: Tom Lendacky
Signed-off-by: Suravee Suthikulpanit
---
drivers/crypto/ccp/ccp-platform.c | 60 +--
Currently, amd-xgbe driver has separate logic to determine device
coherency for DT vs. ACPI. This patch simplifies the code with
a call to device_dma_is_coherent().
Signed-off-by: Tom Lendacky
Signed-off-by: Suravee Suthikulpanit
---
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +-
On 5/20/2015 5:28 AM, Will Deacon wrote:
On Fri, May 15, 2015 at 10:23:12PM +0100, Suravee Suthikulpanit wrote:
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
Th
Hi Cong,
On Wed, May 20, 2015, at 22:59, Cong Wang wrote:
> On Wed, May 20, 2015 at 8:35 AM, Hannes Frederic Sowa
> wrote:
> >
> > -static int unix_stream_recvmsg(struct socket *sock, struct msghdr *msg,
> > - size_t size, int flags)
> > +struct unix_stream_read_state
When trying to configure the settings for PHY1, using commands
like 'ethtool -s eth0 phyad 1 speed 100', the 'ethtool' seems to
modify other settings apart from the speed of the PHY1, in the
above case.
The ethtool seems to query the settings for PHY0, and use this
as the base to apply the new set
Hi,
This patch fixes an issue while using the 'ethtool' to query/set PHY's
configurations. The 'ethtool' interface in the Kernel seem to always
query settings for PHY0, irrespective of the PHY specified, while
issuing the 'ethtool' command.
For example when issueing 'ethtool -s eth0 phyad 1 speed
On Tue, May 19, 2015 at 2:36 PM, Jesper Dangaard Brouer
wrote:
> +# Threads are specified with parameter -t value in $THREADS
> +for ((thread = 0; thread < $THREADS; thread++)); do
> +dev=${DEV}@${thread}
> +
> +# Add remove all other devices and add_device $dev to thread
> +pg_thread
On 05/20/2015 09:00 AM, Rustad, Mark D wrote:
On May 19, 2015, at 6:02 PM, Alexander Duyck
wrote:
My suspicion is that we have a number of bugs floating around out there like
the Broadcom issue. Specifically, one of the ones I found was that the r8169
seems to have a similar issue as called
On Tue, May 19, 2015 at 2:36 PM, Jesper Dangaard Brouer
wrote:
> +
> +# More generic replacement for pgset(), that does not depend on global
> +# variable for proc file.
> +function proc_cmd() {
> +local result
> +local proc_file=$1
> +# after shift, the remaining args are contained in
Hey everyone,
tl;dr; pure python generic netlink library with simple clients for ipvs
and taskstats here: https://github.com/facebook/gnlpy
At Facebook we rely upon ipvs for most of our layer-4 load balancing
needs. It's mostly worked pretty great for us. The standard way to
interact with
On Wed, May 20, 2015 at 8:35 AM, Hannes Frederic Sowa
wrote:
>
> -static int unix_stream_recvmsg(struct socket *sock, struct msghdr *msg,
> - size_t size, int flags)
> +struct unix_stream_read_state {
> + int (*recv_actor)(struct sk_buff *, int, int,
> +
On Wed, May 20, 2015 at 07:00:25AM -0500, Suravee Suthikulanit wrote:
> On 5/20/2015 4:34 AM, Catalin Marinas wrote:
> >We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise
> >we would need #ifndef here. I already replied, I think for other
> >architectures we need this check to av
On Wed, May 20, 2015 at 10:45:33AM -0700, Jay Vosburgh wrote:
> Michal Kubecek wrote:
>
> >On Tue, May 19, 2015 at 04:29:45AM -0400, Patrick Simmons wrote:
> >> On 05/19/2015 03:49 AM, Michal Kubecek wrote:
> >> >On Tue, May 19, 2015 at 02:09:43AM -0400, Patrick Simmons wrote:
> >> >>
> >> >>I've
I think we have some issues with the e1000e usage of
pci_disable_link_state_locked(), which Yinghai added with 9f728f53dd70
("PCI/e1000e: Add and use pci_disable_link_state_locked()").
That fixed an AER deadlock in the following path, where pci_bus_sem is held
by pci_walk_bus(), and we deadlocked
Directly associate a sampled packet with the path it takes through the virtual
switch.
Path information currently includes mangling, encapsulation and decapsulation
actions
for tunneling protocols GRE, VXLAN, Geneve, MPLS and QinQ, but this extension
requires
no further changes to accommodate da
Hello,
On Wed, 20 May 2015, Ying Xue wrote:
> Yes, this way is absolutely safe for us! But, for example, if we check
> refcnt==0
> in write_lock protection, the checking is a bit late. Instead, if the checking
> is advanced to ip_finish_output2(), we can _early_ find the fact that we
>
On 05/13/2015 03:12 PM, Chris Leech wrote:
This is only about the structures and functionality involved in maintaining the
iSCSI session, the SCSI host along with it's discovered targets and devices has
no association with network namespaces.
These patches are functional, but not complete. Ther
On Wed, May 20, 2015 at 8:35 AM, Hannes Frederic Sowa
wrote:
>
> +static ssize_t unix_stream_sendpage(struct socket *socket, struct page *page,
> + int offset, size_t size, int flags)
> +{
> + int err;
> + bool send_sigpipe;
> + struct sock *sk,
On Wed, 2015-05-20 at 11:13 -0700, Vijay Subramanian wrote:
> Hi Daniel,
>
> With this commit, ifconfig does not show any of the interfaces and I
> don't have any connectivity as a result.
> Can you double check this?
Please do not top post.
No problem here. I do not see obvious reasons for brea
On Wed, 2015-05-20 at 20:12 +0200, Daniel Borkmann wrote:
> Effectively, every in-tree classifier (rsvp is the only exception)
> is making use of call_rcu(). Moreover, moving this into every
> ->destroy() handler would also be unnecessary overhead, imho, as
> this is only relevant when we actually
On 5/20/15 11:12 AM, Daniel Borkmann wrote:
Effectively, every in-tree classifier (rsvp is the only exception)
is making use of call_rcu(). Moreover, moving this into every
->destroy() handler would also be unnecessary overhead, imho, as
this is only relevant when we actually _unload_ a module.
On Wed, May 20, 2015 at 11:12 AM, Daniel Borkmann wrote:
> On 05/20/2015 07:38 PM, Cong Wang wrote:
> ...
>>
>> Why synchronize_rcu() even matters here? It waits for
>> readers, not for RCU callbacks.
>
>
> Hm, I am mentioning it here as it was related to 78fd1d0ab072
> as explained in the commit
> -Original Message-
> From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
> Sent: Tuesday, May 19, 2015 5:06 PM
> To: Kirsher, Jeffrey T; intel-wired-...@lists.osuosl.org
> Cc: Skidmore, Donald C; Or Gerlitz; David Miller; Linux Netdev List;
> nhor...@redhat.com; sassm...@redhat.com
Hi Daniel,
With this commit, ifconfig does not show any of the interfaces and I
don't have any connectivity as a result.
Can you double check this?
Thanks!
Vijay
On 19 May 2015 at 13:54, David Miller wrote:
> From: Daniel Borkmann
> Date: Tue, 19 May 2015 21:33:42 +0200
>
>> This work as a fol
On 05/20/2015 07:38 PM, Cong Wang wrote:
...
Why synchronize_rcu() even matters here? It waits for
readers, not for RCU callbacks.
Hm, I am mentioning it here as it was related to 78fd1d0ab072
as explained in the commit message.
Since we came here via unregister_tcf_proto_ops(), there
are no
With increase of TCP sockets in hosts, we often hit limitations
caused by port selection, due to randomization and poor strategy.
Eric Dumazet (2):
inet_hashinfo: remove bsocket counter
tcp: improve REUSEADDR/NOREUSEADDR cohabitation
include/net/inet_hashtables.h | 2 --
net/ipv4/inet_con
We no longer need bsocket atomic counter, as inet_csk_get_port()
calls bind_conflict() regardless of its value, after commit
2b05ad33e1e624e ("tcp: bind() fix autoselection to share ports")
This patch removes overhead of maintaining this counter and
double inet_csk_get_port() calls under pressure.
inet_csk_get_port() randomization effort tends to spread
sockets on all the available range (ip_local_port_range)
This is unfortunate because SO_REUSEADDR sockets have
less requirements than non SO_REUSEADDR ones.
If an application uses SO_REUSEADDR hint, it is to try to
allow source ports being
Creat a struct that contain all the resources that needs to be
assigned to the priv struct in stmmac_dvr_probe. This makes it
possible to factor out more common code from the other probe
functions and also use this struct to hold the resources as
they are fetched.
Signed-off-by: Joachim Eastwood
Since the caller already check the presence of a of_node there
is no need to repeat the check in stmmac_probe_config_dt.
There is also no point in checking the return value of the
of_match_device function since if there wasn't match in the
first place we would never be in this function.
Signed-of
This patch set refactor the code in stmmac_pci_probe and stmmac_pltfr_probe
and moves the common bits into stmmac_dvr_probe. Along the way some clean-
ups are applied to stmmac_pltfr_probe.
The code has been tested on the LPC18xx platform.
I am still working on more refactoring of the platform pr
Since stmmac_dvr_probe takes care of setting driver data and
assign resources to the priv structure there is no need to
access the priv structure from the other probe functions.
This mean that this function can be changed into just return
an int and thus simplifying the callers.
Signed-off-by: Joa
Move setting of driver data into stmmac_dvr_probe so the
other probe functions don't have to. This will help to
simplify the other probe functions later.
Signed-off-by: Joachim Eastwood
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_p
> Vijay, can you give this a run on your side? This fixes the panic
> on my side, thanks!
Thanks for the explanation and patch Daniel !
Yes. This also fixes the crash for me. So,
Tested-by: Vijay Subramanian
Vijay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bod
On Wed, May 20, 2015 at 8:35 AM, Hannes Frederic Sowa
wrote:
> +int skb_append_pagefrags(struct sk_buff *skb, struct page *page,
> +int offset, size_t size)
> +{
> + int i = skb_shinfo(skb)->nr_frags;
> +
> + if (skb_can_coalesce(skb, i, page, offset)) {
> +
1 - 100 of 151 matches
Mail list logo
