Re: Re: intel checksum offload
Hi, I'm also curious about why the CSUM_IP was removed in all the intel NICs. Although this thread is very old, I still need the answer because IP checksum offload is actually supported in intel's datasheet. Thanks! 2012-04-14 beezarliu 发件人： YongHyeon PYUN 发送时间： 2011-09-18 04:58:10 收件人： Hooman Fazaeli 抄送： jfv; freebsd-hackers 主题： Re: intel checksum offload On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? After reading this mail, I checked em(4)/lem(4) code and noticed these drivers removed CSUM_IP capability as well. igb(4) didn't support CSUM_IP from day 1 but em(4)/lem(4) used to take advantage of IP checksum offloading capability. Given that these drivers share many code with Linux, Jack may know the details and why IP checksum offloading code was removed. Note, Linux does not use IP checksum offloading so I guess this could be oversight in shared code. BTW, hackers may not be right ML to post this kind of post. CCed to jfv@, the driver maintainer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
It is interesting that how a thread goes off topic! Anyway, I will appreciate if folks, especially Jack, provide a firm comment on the original question: Does intel chips (specifically 82576) support IP TX checksum offload? If so, why the driver does not support it? On 9/19/2011 8:59 AM, Jack Vogel wrote: On Sun, Sep 18, 2011 at 7:48 PM, Arnaud Lacombe lacom...@gmail.com mailto:lacom...@gmail.com wrote: Hi, On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo ri...@iet.unipi.it mailto:ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo ri...@iet.unipi.it mailto:ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN pyu...@gmail.com mailto:pyu...@gmail.com wrote: On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? ... This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the ... [0]: the commit message say performance was not good, but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). optional features are often costly even when disabled. I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. the above suggests that you have a wonderful opportunity: with just a little bit of time and effort you should be able to complete/re-enable the missing code, run tests that you believe significant (given your statement below) and prove or disprove the comment about performance. Which I did about a week ago, to finally discover that the NIC only had only 3 MSI-X vectors configured in its EEPROM[0], and thus the MSI-X PCI capability field ends up also with being assigned with those 3 vectors. However, the 82574 datasheet clearly say that up-to 5 vector can be configured, but I obviously did not find the magic trick to make it so. Maybe I'll find some time and try to reprogram the EEPROM. Beside that, it was clear that the old multiqueue did not support only 3 vector being available and thus fell back on MSI. It is not clear in jfv@'s comment whether he really tested multiqueue, or did he test the fall-back MSI mode. As the PCI spec is not public, I've not been able to find out from the few public datasheet how the PCI MSI-X capability field is first programmed. I'd assume that the BIOS is using the data in the NVM to program it at power up. - Arnaud [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, thus 3 vectors. I give answers to those who treat me with respect, I view them as collaborators, we improve the drivers for everyone's benefit, rather than jumping in to throw a critical remark here, a negative innuendo there... If you notice, the Linux driver did not enable multiqueue on the hardware either, so do you think a whole department of software engineers backed by the hardware engineers who designed the damn thing might have had a reason? IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and tried it for a while just because I could, implementing the code was not difficult. Over time however that code proved to be a source of instability and thus was disabled. I have heard a rumor that the Linux crew may actually be trying a second time to make it work, and that might give me cause to look at it again too, but its not clear if I'll have time with other priorities. Jack ___ freebsd
Re: intel checksum offload
Arnaud (and others), Liaising with vendors is not an easy task. The reason why Intel (and other vendors) don't supply detailed history and reasoning for their development efforts is that their engineers are likely tasked with making it work versus writing lots of stuff down for public release. In some instances, the vendor support of FreeBSD (and free open source in general) is done as a side-project by some of the engineers inside the company. So in this case, you may find that Jack and the other engineers at Intel just don't have the time or resources to dedicate the kinds of feedback and support you seem to be after. He and others likely have a huge set of tasks to do at work and none of them officially include support FreeBSD/Linux developers by providing detailed feedback and assistance. So whenever Jack pops up to help out, he's likely doing it in his spare time. :-) Developers can and will disable or remove functionality which is problematic because they don't have the time or resources to support it. Users may wish to turn on unsupported features and then will complain loudly when they don't work; even giving up and moving to another piece of equipment because of perceived issues. I agree that it would be nice if the developers included _all_ features, unsupported or not, so that developers can choose to work on them if they wish. It however is a trade-off between trying to provide developers with more useful things to tinker with and not increasing support load from users (and other developers) who seek to use incomplete features. I hope this helps. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
On Sun, Sep 18, 2011 at 7:48 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? ... This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the ... [0]: the commit message say performance was not good, but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). optional features are often costly even when disabled. I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. the above suggests that you have a wonderful opportunity: with just a little bit of time and effort you should be able to complete/re-enable the missing code, run tests that you believe significant (given your statement below) and prove or disprove the comment about performance. Which I did about a week ago, to finally discover that the NIC only had only 3 MSI-X vectors configured in its EEPROM[0], and thus the MSI-X PCI capability field ends up also with being assigned with those 3 vectors. However, the 82574 datasheet clearly say that up-to 5 vector can be configured, but I obviously did not find the magic trick to make it so. Maybe I'll find some time and try to reprogram the EEPROM. Beside that, it was clear that the old multiqueue did not support only 3 vector being available and thus fell back on MSI. It is not clear in jfv@'s comment whether he really tested multiqueue, or did he test the fall-back MSI mode. As the PCI spec is not public, I've not been able to find out from the few public datasheet how the PCI MSI-X capability field is first programmed. I'd assume that the BIOS is using the data in the NVM to program it at power up. - Arnaud [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, thus 3 vectors. I give answers to those who treat me with respect, I view them as collaborators, we improve the drivers for everyone's benefit, rather than jumping in to throw a critical remark here, a negative innuendo there... If you notice, the Linux driver did not enable multiqueue on the hardware either, so do you think a whole department of software engineers backed by the hardware engineers who designed the damn thing might have had a reason? IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and tried it for a while just because I could, implementing the code was not difficult. Over time however that code proved to be a source of instability and thus was disabled. I have heard a rumor that the Linux crew may actually be trying a second time to make it work, and that might give me cause to look at it again too, but its not clear if I'll have time with other priorities. Jack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
On Sunday, September 18, 2011 10:48:32 pm Arnaud Lacombe wrote: As the PCI spec is not public, I've not been able to find out from the few public datasheet how the PCI MSI-X capability field is first programmed. I'd assume that the BIOS is using the data in the NVM to program it at power up. PCI System Architecture is quite public at Amazon. It's not the spec, but it will certainly give you enough info to understand MSI and it covers the question you are asking well enough. The MSI config registers are not touched by the BIOS at all (at least not in a standard way). It is the responsibility of the device to setup the read-only fields in the MSI and MSI-X config registers on reset. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
Hi, On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd adr...@freebsd.org wrote: Arnaud (and others), Liaising with vendors is not an easy task. The reason why Intel (and other vendors) don't supply detailed history and reasoning for their development efforts is that their engineers are likely tasked with making it work versus writing lots of stuff down for public release. In some instances, the vendor support of FreeBSD (and free open source in general) is done as a side-project by some of the engineers inside the company. So in this case, you may find that Jack and the other engineers at Intel just don't have the time or resources to dedicate the kinds of feedback and support you seem to be after. He and others likely have a huge set of tasks to do at work and none of them officially include support FreeBSD/Linux developers by providing detailed feedback and assistance. So whenever Jack pops up to help out, he's likely doing it in his spare time. :-) Yes, and he seems to really like to waste his spare time by repeating me for two months to increase `kern.ipc.nmbclusters' to fix issue I was seeing, when the code was clearly buggy, even when I sent him patchs fixing issues. That's sure a very efficient way of managing time. - Arnaud Developers can and will disable or remove functionality which is problematic because they don't have the time or resources to support it. Users may wish to turn on unsupported features and then will complain loudly when they don't work; even giving up and moving to another piece of equipment because of perceived issues. I agree that it would be nice if the developers included _all_ features, unsupported or not, so that developers can choose to work on them if they wish. It however is a trade-off between trying to provide developers with more useful things to tinker with and not increasing support load from users (and other developers) who seek to use incomplete features. I hope this helps. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: checksum offload
The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? The first question is is checksum offload a good idea? There is less protection against errors. This assumes firmware flaws, right? Albeit, it also does confuse some software like tcpdump. Unfortunately lots of high performance people use checksum offload which removes much of the end to end protection Alan Cox http://kerneltrap.org/Linux/Data_Errors_During_Drive_Communication Bugs in the hardware/firmware/software are not required to have a problem, but if present would make things even worse. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
On Mon, Sep 19, 2011 at 10:17:22AM -0400, Arnaud Lacombe wrote: Hi, On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd adr...@freebsd.org wrote: Arnaud (and others), Liaising with vendors is not an easy task. The reason why Intel (and other vendors) don't supply detailed history and reasoning for their development efforts is that their engineers are likely tasked with making it work versus writing lots of stuff down for public release. In some instances, the vendor support of FreeBSD (and free open source in general) is done as a side-project by some of the engineers inside the company. So in this case, you may find that Jack and the other engineers at Intel just don't have the time or resources to dedicate the kinds of feedback and support you seem to be after. He and others likely have a huge set of tasks to do at work and none of them officially include support FreeBSD/Linux developers by providing detailed feedback and assistance. So whenever Jack pops up to help out, he's likely doing it in his spare time. :-) Yes, and he seems to really like to waste his spare time by repeating me for two months to increase `kern.ipc.nmbclusters' to fix issue I was seeing, when the code was clearly buggy, even when I sent him patchs fixing issues. If you think you encountered a driver bug, could you share it with us? I didn't closely follow em(4)/lem(4)/igb(4) changes for a long time so I'm not sure whether I can come up with reasonable fix for the issue but I may be able to help you. That's sure a very efficient way of managing time. - Arnaud Developers can and will disable or remove functionality which is problematic because they don't have the time or resources to support it. Users may wish to turn on unsupported features and then will complain loudly when they don't work; even giving up and moving to another piece of equipment because of perceived issues. I agree that it would be nice if the developers included _all_ features, unsupported or not, so that developers can choose to work on them if they wish. It however is a trade-off between trying to provide developers with more useful things to tinker with and not increasing support load from users (and other developers) who seek to use incomplete features. I hope this helps. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
Hi, On Mon, Sep 19, 2011 at 12:59 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Mon, Sep 19, 2011 at 10:17:22AM -0400, Arnaud Lacombe wrote: Hi, On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd adr...@freebsd.org wrote: Arnaud (and others), Liaising with vendors is not an easy task. The reason why Intel (and other vendors) don't supply detailed history and reasoning for their development efforts is that their engineers are likely tasked with making it work versus writing lots of stuff down for public release. In some instances, the vendor support of FreeBSD (and free open source in general) is done as a side-project by some of the engineers inside the company. So in this case, you may find that Jack and the other engineers at Intel just don't have the time or resources to dedicate the kinds of feedback and support you seem to be after. He and others likely have a huge set of tasks to do at work and none of them officially include support FreeBSD/Linux developers by providing detailed feedback and assistance. So whenever Jack pops up to help out, he's likely doing it in his spare time. :-) Yes, and he seems to really like to waste his spare time by repeating me for two months to increase `kern.ipc.nmbclusters' to fix issue I was seeing, when the code was clearly buggy, even when I sent him patchs fixing issues. If you think you encountered a driver bug, could you share it with us? I didn't closely follow em(4)/lem(4)/igb(4) changes for a long time so I'm not sure whether I can come up with reasonable fix for the issue but I may be able to help you. They ended up being fixed, thanks :-) Now, up until next week, we were struggle on the mbuf corruption I reported on freebsd-net@, but I do not think it is a driver issue per-se. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? After reading this mail, I checked em(4)/lem(4) code and noticed these drivers removed CSUM_IP capability as well. igb(4) didn't support CSUM_IP from day 1 but em(4)/lem(4) used to take advantage of IP checksum offloading capability. Given that these drivers share many code with Linux, Jack may know the details and why IP checksum offloading code was removed. Note, Linux does not use IP checksum offloading so I guess this could be oversight in shared code. BTW, hackers may not be right ML to post this kind of post. CCed to jfv@, the driver maintainer. This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the 82574 supports multiqueue (at least should support up to 5 MSI-X vectors, 2 RX and 2 TX), but this support was removed from em(4) in mid-2010[0]. Also, the 82571 and the 82574 should also support header split, but this is currently only implemented in igb(4), not em(4). - Arnaud [0]: the commit message say performance was not good, but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? ... This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the ... [0]: the commit message say performance was not good, but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). optional features are often costly even when disabled. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? ... This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the ... [0]: the commit message say performance was not good, but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). optional features are often costly even when disabled. I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. Now I might also openly question the test method used by the folks at Intel, just seeing how much issue I've had with the driver (I still have for some, even if not driver related), which have not been reproduced there. Finally, when someone say performance are better that way, the first thing I'd be tempted to ask is: What is your test ? How did you collects the numbers ? How did you reach the conclusion ?. None of this stuff is public. regards, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: checksum offload
The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? The first question is is checksum offload a good idea? There is less protection against errors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: checksum offload
On Sun, Sep 18, 2011 at 5:23 PM, Dieter BSD dieter...@engineer.com wrote: The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? The first question is is checksum offload a good idea? There is less protection against errors. This assumes firmware flaws, right? Albeit, it also does confuse some software like tcpdump. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? ... This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the ... [0]: the commit message say performance was not good, but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). optional features are often costly even when disabled. I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. the above suggests that you have a wonderful opportunity: with just a little bit of time and effort you should be able to complete/re-enable the missing code, run tests that you believe significant (given your statement below) and prove or disprove the comment about performance. cheers luigi Now I might also openly question the test method used by the folks at Intel, just seeing how much issue I've had with the driver (I still have for some, even if not driver related), which have not been reproduced there. Finally, when someone say performance are better that way, the first thing I'd be tempted to ask is: What is your test ? How did you collects the numbers ? How did you reach the conclusion ?. None of this stuff is public. regards, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
.. and believe me, lots of people will appreciate it if you can verify/diagnose issues. :) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
Hi, On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? ... This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the ... [0]: the commit message say performance was not good, but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). optional features are often costly even when disabled. I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. the above suggests that you have a wonderful opportunity: with just a little bit of time and effort you should be able to complete/re-enable the missing code, run tests that you believe significant (given your statement below) and prove or disprove the comment about performance. Which I did about a week ago, to finally discover that the NIC only had only 3 MSI-X vectors configured in its EEPROM[0], and thus the MSI-X PCI capability field ends up also with being assigned with those 3 vectors. However, the 82574 datasheet clearly say that up-to 5 vector can be configured, but I obviously did not find the magic trick to make it so. Maybe I'll find some time and try to reprogram the EEPROM. Beside that, it was clear that the old multiqueue did not support only 3 vector being available and thus fell back on MSI. It is not clear in jfv@'s comment whether he really tested multiqueue, or did he test the fall-back MSI mode. As the PCI spec is not public, I've not been able to find out from the few public datasheet how the PCI MSI-X capability field is first programmed. I'd assume that the BIOS is using the data in the NVM to program it at power up. - Arnaud [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, thus 3 vectors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
Hi, On Mon, Sep 19, 2011 at 12:29 AM, Jack Vogel jfvo...@gmail.com wrote: [...] If you notice, the Linux driver did not enable multiqueue on the hardware either, so do you think a whole department of software engineers backed by the hardware engineers who designed the damn thing might have had a reason? Let's find out :-) In the mean time, as a hacker, I'd be interested to know why the NVM ships with MSI_X_NUM == 2 at offset 0x1b when the datasheet say it does support up value to 4 ? This might be as simple as the hardware needs special wiring to support 5 vectors., or whatever... IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and tried it for a while just because I could, implementing the code was not difficult. Over time however that code proved to be a source of instability and thus was disabled. It would be interesting for the records to have this information public, especially the kind of instability seen. I have heard a rumor that the Linux crew may actually be trying a second time to make it work, and that might give me cause to look at it again too, but its not clear if I'll have time with other priorities. ack. Now, what about header-split support in em(4) ? Thanks, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
intel checksum offload
Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intel checksum offload
On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: Hi list, The data sheet for intel 82576 advertises IP TX/RX checksum offload but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that driver (and chip) do not support IP TX checksum offload or the support for TX is not yet included in the driver? After reading this mail, I checked em(4)/lem(4) code and noticed these drivers removed CSUM_IP capability as well. igb(4) didn't support CSUM_IP from day 1 but em(4)/lem(4) used to take advantage of IP checksum offloading capability. Given that these drivers share many code with Linux, Jack may know the details and why IP checksum offloading code was removed. Note, Linux does not use IP checksum offloading so I guess this could be oversight in shared code. BTW, hackers may not be right ML to post this kind of post. CCed to jfv@, the driver maintainer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Bugfix for checksum offload in bge(4)
On Fri, May 21, 2004 at 11:11:41PM +0900, George V.Neville-Neil wrote: While sweeping network interface drivers for incorrect usage of the capabilities framework, I noticed some bugs in bge(4). Unfortunately, I have no such card and I don't know its internals. Therefore I made a patch fixing hw-independent bugs and marking some questionable spots. It would be nice if somebody possessing the knowledge on bge(4) reviewed this patch and used it to really fix the things. If nobody undertakes that, I'll just commit my change since it doesn't seem to affect the functionality while it brings the code into the shape. Thanks! I have such a card and can look into this. It may take a bit though, perhaps a week or so. Thank you George, that would be great. A week is not a problem after it took me two months to spare time to make the patch :-) -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bugfix for checksum offload in bge(4)
While on the subject of bge any idea why it performs so poorly in 100Mb mode when compared to the humble fxp in the following results. quote=Why is MySQL nearly. FreeBSD 5.1.2 (i386) local: 22834.872368421 records per second fxp 100Mb: 3854.06863517 records per second bge 100Mb: 2501.66999862 records per second bge 1Gb: 3281.65229885 records per second /quote Connection is TCP based with fairly small packets but at high volumes fxp was pushing 4k packets / s where bge would only do around 2.5k Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
