Hi Shirley,
I guess you missed my response to your comments too. They're attached.
On Mon, 2007-12-10 at 08:45 -0800, Shirley Ma wrote:
> Hello Eli,
>
> I just found my email somehow became SPAM. I just resent my comments,
> hopefully it can go through.
>
> Eli Cohen <[EMAIL PROTECTED]> wrote on 12/02/2007 05:45:59 AM:
>
> > On Fri, 2007-11-30 at 15:28 -0800, Shirley Ma wrote:
> > > I just touch tested ofed-1.3 beta IPoIB. And found there was a
> kernel
> > > parameter hw_csum being added in IPoIB. I have several questions
> here:
> > > 1. Why not using ethtool to set up these HW_CSUM flags?
> > There is no adequate interface in Ethtool for doing it so we use a
> > module parameter. This is because we see this as a static
> configuration
> > per host.
>
> Ethtool does support rx csum and tx csum:
> #define ETHTOOL_GRXCSUM 0x00000014 Get RX hw csum enable
> (ethtool_value)
> #define ETHTOOL_SRXCSUM 0x00000015 Set RX hw csum enable
> (ethtool_value)
> #define ETHTOOL_GTXCSUM 0x00000016 Get TX hw csum enable
> (ethtool_value)
> #define ETHTOOL_STXCSUM 0x00000017 /* Set TX hw csum enable
> (ethtool_value)
>
> We should use ethtool here.
>
> > > 2. I haven't looked at the detailed code yet, is that possible
> with this
> > > flag, TCP/IP will not do CSUM for HCA which has no TCP/IP offload
> support?
> > Yes, the HCA need not have checksum offload support. the idea is the
> IB
> > ICRC provides the insurance that the packets are not corrupt.
>
> That's something we discussed long time ago when we wanted GSO to
> avoid extra copy by using ICRC to enable SG feature. I remembered
> Roland rejected this idea since there could be potenical data
> corruption. And even if we do prove that ICRC is 100% accurate, then
> we should have some codes here to limit the IP destination within IB
> subnet when using ICRC. Otherwise, if the packets routing out to
> ehthernet IP subnet, these packets will be dropped.
>
> Thanks
> Shirley
>
--- Begin Message ---
On Mon, 2007-12-03 at 15:19 -0800, Shirley Ma wrote:
> Ethtool does support rx csum and tx csum:
> #define ETHTOOL_GRXCSUM 0x00000014 /* Get RX hw csum enable
> (ethtool_value) */
> #define ETHTOOL_SRXCSUM 0x00000015 /* Set RX hw csum enable
> (ethtool_value) */
> #define ETHTOOL_GTXCSUM 0x00000016 /* Get TX hw csum enable
> (ethtool_value) */
> #define ETHTOOL_STXCSUM 0x00000017 /* Set TX hw csum enable
> (ethtool_value) */
>
I believe this configuration relates to checksum generation/validation
of the device and not to this specific feature.
> That's something we discussed long time ago when we wanted GSO to
> avoid extra copy by using ICRC to enable SG feature. I remembered
> Roland rejected this idea since there could be potenical data
> corruption. And even if we do prove that ICRC is 100% accurate, then
> we should have some codes here to limit the IP destination within IB
> subnet when using ICRC. Otherwise, if the packets routing out to
> ehthernet IP subnet, these packets will be dropped.
>
I agree that we should not let a node configured to route packets, to
work at this mode.
But what if we use this rule:
if a node is configured, by root user, for ip forwarding then that root
user should make sure not to enable this feature.
Does this make sense?
--- End Message ---
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
