Re: linux-next: manual merge of the net-next tree with the net tree

On 12/1/20 7:20 PM, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/ibm/ibmvnic.c between commit: b71ec9522346 ("ibmvnic: Ensure that SCRQ entry reads are correctly ordered") from the net tree and commit: ec20f36

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

On 10/27/2016 10:26 AM, Eric Dumazet wrote: > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote: >> We recently encountered a bug where a few customers using ibmveth on the >> same LPAR hit an issue where a TCP session hung when large receive was >> enabled. Closer analysis revealed that the se

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

stomers tests. > > Signed-off-by: Jon Maxwell Thanks, Jon. Acked-by: Thomas Falcon > --- > drivers/net/ethernet/ibm/ibmveth.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/drivers/net/ethernet/ibm/ibmveth.c > b/drivers/net/ethernet/ibm/i

Re: [PATCHv2] ibmveth: Fix off-by-one error in ibmveth_change_mtu()

er only permits a maximum MTU of 65513. This is because there is a < > instead of an <= in ibmveth_change_mtu(), which only permits an MTU which > is strictly smaller than the buffer size, rather than allowing the buffer > to be completely filled. > > This patch fixes the buglet.

Re: [PATCH] ibmveth: Fix off-by-one error in ibmveth_change_mtu()

On 04/13/2015 12:39 AM, David Gibson wrote: > AFAIK the PAPR document which defines the virtual device interface used by > the ibmveth driver doesn't specify a specific maximum MTU. So, in the > ibmveth driver, the maximum allowed MTU is determined by the maximum > allocated buffer size of 64k (co