diff for duplicates of <4C067EF7.9040609@netservers.co.uk> diff --git a/a/1.txt b/N1/1.txt index cd1d4fa..76aa353 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -13,7 +13,7 @@ as your code does, so that makes sense. > > flen = len; > if (nfree > 0) { -> if (pch->speed = 0) { +> if (pch->speed == 0) { > - flen = totlen/nfree; > + if (nfree > 1) > + flen = DIV_ROUND_UP(len, nfree); @@ -28,13 +28,13 @@ iteration of the loop whereas 'totlen' remains unchanged. Thus give roughly the same. However, without rounding up here I'm not sure the logic is right either, since the side effect of nbigger is to make len decrease faster so it is not quite proportional to the decrease in -nfree. Is there a risk of ending up on the nfree = 1 iteration with -flen = len - 1 and thus generating a superfluous extra 1 byte long +nfree. Is there a risk of ending up on the nfree == 1 iteration with +flen == len - 1 and thus generating a superfluous extra 1 byte long fragment? This would be a far worse situation than a slight imbalance in the size of the fragments. Perhaps the solution is to go back to a precalculated fragment size for -the pch->speed = 0 case as per original code? +the pch->speed == 0 case as per original code? Regards, Ben. diff --git a/a/content_digest b/N1/content_digest index 9985f16..eefa843 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,7 +3,7 @@ "ref\0DF7BB929B28FCF479E888E3D9F8D9E88D3E16B5A@irsmsx502.ger.corp.intel.com\0" "From\0Ben McKeegan <ben@netservers.co.uk>\0" "Subject\0Re: [PATCH] ppp_generic: fix multilink fragment sizes\0" - "Date\0Wed, 02 Jun 2010 15:55:35 +0000\0" + "Date\0Wed, 02 Jun 2010 16:55:35 +0100\0" "To\0Paoloni" " Gabriele <gabriele.paoloni@intel.com>\0" "Cc\0davem@davemloft.net <davem@davemloft.net>" @@ -29,7 +29,7 @@ "> \n" "> \t\tflen = len;\n" "> \t\tif (nfree > 0) {\n" - "> \t\t\tif (pch->speed = 0) {\n" + "> \t\t\tif (pch->speed == 0) {\n" "> -\t\t\t\tflen = totlen/nfree;\n" "> +\t\t\t\tif (nfree > 1)\n" "> +\t\t\t\t\tflen = DIV_ROUND_UP(len, nfree);\n" @@ -44,15 +44,15 @@ "give roughly the same. However, without rounding up here I'm not sure \n" "the logic is right either, since the side effect of nbigger is to make \n" "len decrease faster so it is not quite proportional to the decrease in \n" - "nfree. Is there a risk of ending up on the nfree = 1 iteration with \n" - "flen = len - 1 and thus generating a superfluous extra 1 byte long \n" + "nfree. Is there a risk of ending up on the nfree == 1 iteration with \n" + "flen == len - 1 and thus generating a superfluous extra 1 byte long \n" "fragment? This would be a far worse situation than a slight imbalance \n" "in the size of the fragments.\n" "\n" "Perhaps the solution is to go back to a precalculated fragment size for \n" - "the pch->speed = 0 case as per original code?\n" + "the pch->speed == 0 case as per original code?\n" "\n" "Regards,\n" Ben. -8668425d938fb791547208bdf8513866d58afdcdfb6ab4ab552ae8138cc99ae1 +188b53939ada8be991780e1799950b0eb5b4f795168f341e3319b5fae46184ec
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.