lkml.org 
[lkml]   [2016]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers
On Oct 22 Stefan Richter wrote:
> On Oct 19 Jarod Wilson wrote:
> > On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > > On Oct 19 Sabrina Dubroca wrote:
> > > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
[...]
> > > > > @@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
> > > > > max_mtu = (1 << (card->max_receive + 1))
> > > > > - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > > > net->mtu = min(1500U, max_mtu);
> > > > > + net->min_mtu = ETH_MIN_MTU;
> > > > > + net->max_mtu = net->mtu;
> > > >
> > > > But that will now prevent increasing the MTU above the initial value?
> > >
> > > Indeed, therefore NAK.
> >
> > However, there's an explicit calculation for 'max_mtu' right there that I
> > glazed right over. It would seem perhaps *that* should be used for
> > net->max_mtu here, no?
>
> No. This 'max_mtu' here is not the absolute maximum. It is only an
> initial MTU which has the property that link fragmentation is not
> going to happen (if all other peers will at least as capable as this
> node).

Besides, card->max_receive is about what the card can receive (at the IEEE
1394 link layer), not about what the card can send.
--
Stefan Richter
-======----- =-=- =-==-
http://arcgraph.de/sr/

\
 
 \ /
  Last update: 2016-10-22 20:53    [W:0.078 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site