> 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
> > b
> 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"
> 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
> 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
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
> 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 FIN_WAIT1 and then
> > FIN_
> 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 up
> 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 does not it can always report true. With a new
> >
> 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 both carrier and link sta
> From: Jay Vosburgh [mailto:jay.vosbu...@canonical.com]
> Debabrata Banerjee wrote:
> >-if
> (!ether_addr_equal_64bits(rx_hash_table[index].mac_dst,
> >- mac_bcast) &&
> >-
> !is_zero_ether_addr(rx_hash_table[ind
> 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
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 understand the need to switch t
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
>>
>
>May I ask what is exactly
13 matches
Mail list logo
