Re: [PATCH net-next v2] macvlan: Support interface operstate properly

On 4/7/16, 7:05 AM, "Nikolay Aleksandrov" wrote: >On 04/07/2016 12:36 AM, Debabrata Banerjee wrote: >> Set appropriate macvlan interface status based on lower device and our >> status. Can be up, down, or lowerlayerdown. >What about dormant ? > >That being said I

Re: [PATCH] macvlan: Support interface operstate properly

On 4/6/16, 5:03 PM, "Nikolay Aleksandrov" wrote: >On 04/06/2016 10:30 PM, Debabrata Banerjee wrote: >> Set appropriate macvlan interface status based on lower device and our >> status. Can be up, down, or lowerlayerdown. >> >> Signed-off-by: Debabrata Banerjee

RE: [PATCH] Fix handling of verdicts after NF_QUEUE

> From: Pablo Neira Ayuso [mailto:pa...@netfilter.org] > On Mon, Dec 11, 2017 at 06:30:24PM -0500, Debabrata Banerjee wrote: > > + } else { > > + /* Implicit handling for NF_STOLEN, as well as any other > > +* non conventional verdicts. > > +*/ > > +

RE: [PATCH net-next 4/4] bonding: allow carrier and link status to determine link state

> From: Jay Vosburgh [mailto:jay.vosbu...@canonical.com] > Debabrata Banerjee wrote: > > >In a mixed environment it may be difficult to tell if your hardware > >support carrier, if it does not it can always report true. With a new > >use_carrier option of 2, we can check

RE: [PATCH net-next 2/4] bonding: use common mac addr checks

> From: Jay Vosburgh [mailto:jay.vosbu...@canonical.com] > Debabrata Banerjee wrote: > >-if > (!ether_addr_equal_64bits(rx_hash_table[index].mac_dst, > >- mac_bcast) && > >- >

RE: [PATCH RFC net-next 1/1] tcp: close socket without reset on incoming data

> From: David Miller [mailto:da...@davemloft.net] > From: Debabrata Banerjee > > > When TCP_CLOSE_NORST is set before a close(), offload sinking of > > unwanted data to the kernel with low resource usage, with a timeout of > > TCP_LINGER2. The socket will transition to

RE: [PATCH net-next v2 4/4] bonding: allow carrier and link status to determine link state

> From: David Miller [mailto:da...@davemloft.net] > From: Jay Vosburgh > Date: Wed, 16 May 2018 18:11:08 +0200 > > > Debabrata Banerjee wrote: > > > >>In a mixed environment it may be difficult to tell if your hardware > >>support carrier, if it

RE: [PATCH net-next v2 4/4] bonding: allow carrier and link status to determine link state

> From: David Miller [mailto:da...@davemloft.net] > > Looking at the bnx2x driver, it's management of link state is very convoluted. > > The link parameters and the "link_up" state is maintained separately from > the values that are snapshot when the carrier is enabled. ... > If the carrier is

Re: [PATCH net-next] netpoll: allow cleanup to be synchronous

Actually I realized this patch might be problematic, although someone might be holding rtnl, it might not be the current callstack. A different solution is needed I think. Input appreciated. -Deb

RE: [PATCH net-next] netpoll: allow cleanup to be synchronous

> From: Neil Horman > The team driver still seems > to be an outlier there though I think , in that it doesn't guarantee the > holding > of rtnl in its port add/delete paths. Not seeing where this is the case in the team driver today? They were actually calling __netpoll_cleanup synchronously

RE: [PATCH net-next] netpoll: allow cleanup to be synchronous

> From: Neil Horman > Agreed, this doesn't make sense. If you want a synchronous cleanup, create > a wrapper function that creates a wait queue, calls __netpoll_free_async, > and blocks on the wait queue completion. Modify the cleanup_work > method(s) to complete the wait queue, and you've got

RE: [PATCH net-next v2] netpoll: allow cleanup to be synchronous

> From: Neil Horman > I presume you've tested this with some of the stacked devices? I think I'm > ok with this change, but I'd like confirmation that its worked. > > Neil Yes I've tested this on a bond device with vlan stacked on top. -Deb > > > CC: Neil Horman > > CC: "David S. Miller"

RE: [PATCH RFC net-next] net: vlan/macvlan: count packets properly with gso

> From: Eric Dumazet > On 11/29/2018 01:13 PM, Duyck, Alexander H wrote: > > > > Also your bytes are going to be totally messed up as well since the > > headers are trimmed in the GSO frames. It might be worthwhile to just > > have a branch based on skb_is_gso that sets the packets and bytes > >